Most Helpful Customer Reviews
|
|
8 of 8 people found the following review helpful:
4.0 out of 5 stars
Covers all I wanted to know about transactions--and more, August 15, 2004
Since many financial institutions have standardized on it, I hear Java is the new COBOL. Whether or not this is true, if Java is to become the business language of choice, transaction support is crucial. (By 'transaction,' I mean 'allowing two or more decisions to me made under ACID constraints: atomically, consistently, (as) in isolation and durably'.) Over the last five ears, the Java platform has grown by leaps and bounds, not least in this area.
Java Transaction Processing by Mark Little, Jon Maron and Greg Pavlik, explores transactions and their relationship with the Java language and libraries. Starting with basic concepts of transactions, both local and distributed, including the roles of participant and coordinator, and the idea of transaction context, the book covers much old but useful ground. Then, by covering the Java Transaction API (JTA) as well as OTS, the OMG's transaction API which is JTA's foundation, this book provides a solid understanding of the complexities of transactions for Java programmers who haven't dealt with anything more complex than a single RDBMS. I'd say these complexities could be summed up simply: failures happen; how can you deal with them reliably and quickly?
The book then goes on to examine transactions and the part they play in major J2EE APIs: Java Database Connectivity (JDBC), Java Message Service (JMS), Enterprise Java Beans (EJB) and J2EE Connector Architecture (JCA). These chapters were interesting overviews of these technologies, and would be sufficient to begin programming in them. However, they are complex, and a single chapter certainly can't do justice to any of the APIs. If you're new to them, expect to buy another book.
In the last section, the authors discuss the future of transactions, especially long running activities (the Java Activity Service) and web services. This was the most interesting section to me, but also is the most likely to age poorly. These technologies are all still under development; the basic concepts, however, seem likely to remain useful for some time. And, if you need to decide on a web service transaction API yesterday, don't build your own, read chapter 10.
There were some things I didn't like about Java Transaction Processing. Some of the editing was sloppy-periods or words missing. This wasn't too big a problem for me, since the publisher provided me a free copy for review, but if I were paying list price ($50) I'd be a bit miffed. A larger annoyance was incorrect UML and Java code snippets. Again, the meaning can be figured out from the text, but it's a bit frustrating. Finally, while the authors raise some very valid points about trusting, or not, the transaction system software provider, I felt the constant trumpeting of HP and Arjuna technologies was a bit tedious. Perhaps these companies are on the forefront of Java transactions (possible); perhaps the authors are most familiar with the products of these companies (looking at the biographies, this is likely). The warnings-find out who is writing the transaction software, which is probably at the heart of your business, and how often they've written such software before-were useful, if a bit repetitive.
That said, this book was still a good read, if a bit long (~360 pages). I think that Java Transaction Processing would be especially useful for an enterprise architect looking to leverage existing (expensive) transactional systems with more modern technology, and trying to see how Java and its myriad APIs fit into the mix. (This is what I imagine, because I'm not an enterprise architect.) I also think this book would be useful to DBAs; knowing about the Java APIs and how they deal with transactions would definitely help a DBA discuss software issues with a typical Java developer.
To me, an average Java developer, the first section of the book was the most useful. While transactions are fairly simple to explain (consider the canonical bank account example), this section illuminated complexities I'd not even thought of-optimizations, heuristic outcomes, failure recovery. These issues occur even in fairly simple setups-I'm working at a client who wants to update two databases with different views of the same information, but make sure that both are updated or neither; this seems to be a typical distributed transaction. The easiest way to deal with this is to pretend that such updates will always be successful, and then accept small discrepancies. That's fine with click-throughs-money is a different matter.
However, if you are a typical web developer, I'm not sure this book is worth the price. I would borrow it from your company's enterprise architect, as reading it will make you a better programmer (as well as giving you a sense of history-transactions have been around for a long time). But, after digesting fundamental distributed transaction concepts, I won't be referencing this book anytime soon, since the scenarios simply don't happen that often (and when they do, they're often ignored, as outlined above).
|
|
|
6 of 6 people found the following review helpful:
4.0 out of 5 stars
All J2EE developers should read this book., September 2, 2004
This is not a book for beginners. It assumes knowledge of Java and as well as a fairly broad knowledge of various other technologies. However, I did find it to be quite readable considering its complex subject matter, with an excellent balance between theory, practice, and illustrative examples. Many J2EE application developers do not understand two phase commit transactions, and hence have little understanding of, for example, the consequences of involving messaging and database operations in the one transction. I would highly recommend this book to all J2EE developers as an excellent way to address this ignorance, and as an eye opener to the possibilities of alternative transaction models.
Much of the book is devoted to two phase commit transactions:
- How they are implemented. Almost enough information to implement one yourself (though they strongly recommend against trying!)
- The Object Transaction Service Architecture on which the Java Transaction API is based: this section has considerable detail made surprisingly readable by numerous sequence diagrams.
- Heuristic Decisions: detailing the meanings of the different heuristic outcomes, such as heurist-rollback, heuristic-commit, heuristic-mixed, and heuristic-hazard.
- Optimizations: presumed-abort; one-phase; read-only; and last-resource-commit.
- The implications for database access and messaging (JMS), and information on the approaches taken by different vendors.
- The implications for EJB and other J2EE programming.
- Optimistic vs pessimistic locking schemes, commit options, isolation levels, and transaction context propagation.
- The J2EE Connector Architecture (JCA): its API's and what's involved in creating a resource adaptor.
Other topics are covered in considerable depth, including:
- The J2EE Activity Service as a framework for supporting alternative transaction models to the standard ACID model. For example, it lets you define a transaction in terms of a sequence of actions and any required compensation actions required upon failures.
- Transactions & Web Services: describing a number of different specificiations that have been defined and implemented for supporting distributed transactions over web services.
|
|
|
6 of 6 people found the following review helpful:
4.0 out of 5 stars
packed with material, July 16, 2004
"Java Transaction Processing" explains how to use different types of transactions in Java and J2EE programs. The authors state the audience is architects and senior developers. I agree and would recommend beginners read a different book first. There isn't any fluff in this book. They even separate the history into an appendix. The transaction coverage is quite thorough.The introduction leaps right into transaction concepts. They range from the simple (ACID) to the complex (heuristics.) If you don't understand anything in this introduction, read it again. The rest of the book assumes an understanding of all these concepts. The authors balance the complex concepts with a large number of visuals. The most common are flowcharts and UML class/interaction/state diagrams. In chapter one, there are 31 diagrams (in 60 pages) alone. The authors provide an interaction diagram for most code snippets to give you a visual feel. For J2EE topics, the authors provide a brief overview of the topic and end with a detailed example. They also cover features of technologies in the JCP. And what book would be complete without a chapter on web services? The authors include the alternatives and an excellent comparison of each. The authors include many real world issues, best practices and tradeoffs. There is even an appendix on what to consider when buying a transaction implementation and lessons learned. I spotted two minor editing typos, but they don't get in the way of the material. I recommend this book to anyone who uses transactions.
|
|
|
Most Recent Customer Reviews
|
by Philip A. Bernstein
by Gerhard Weikum
by Gregor Hohpe
by Eric Bruno
by Jim Gray
See all Editorial Reviews
