Hi Gregg, Thanks very much, this is very interesting information.
It does confirm what I was trying to clarify in my original email - in this model unless the client is running a transaction manager (which seems unlikely for a phone) the phone is *requesting* the transaction not "executing" the transaction. I do not see anything here which defines how the client would actually execute the transaction, in fact this looks to be out of scope entirely. Also I would be a bit concerned about the "transaction maybe" semantics here. It reminds me a lot of the early app server days, where the app servers would track the transactions requested for back end system execution. If everything went all right, the app server could report success. However, if something went wrong, the app server had no way to initiate recovery. I used to call this "one and a half phase" commit since everything was ok unless you had to recover something. Automatic recovery is definitely the tricky part of 2PC. The Jini transaction spec basically leaves it up to the participating objects whether or not to enforce 2PC semantics. Again, this is fine as long as you do not need to recover update operations against multiple resource managers. While this provides greater flexibility for developers, it also introduces additional risk. This is a classic debate in the TP industry - how much to leave to the programmer's control and how much to guarantee in the software system. In CICS for example, the developer has little if any control over the transaction, since one is always executing and it is virtually impossible to perform an operation on a recoverable resource outside the scope of a transaction. I believe Encina was the first (possibly Tuxedo) to allow significant control by the developer over the ACID properties, and I would say the results were mixed. The OTS specification was created in a classic sort of compromise between OO people who wanted to delegate control completely to the developer and traditional TP folks who wanted the system to enforce the transactional guarantees automatically. The difficulty in layering newer technologies onto existing TP technologies such as transaction managers and recoverable resource managers is that you cannot reinvent those artifacts. In fact the development of a truly reliable and bulletproof transaction manager is a very challenging task. Furthermore one is not going to cause Oracle, DB2, SQL Server etc. to change their behavior simply because you want to give the developer more flexibility - the database cannot lose a transaction, nor can it risk corrupting the customer's data or introducing inconsistencies within it. The Jini model does allow delegation to existing TP infrastructure, which is how it would achieve 2PC, but this means Jini depends upon that infrastructure for the exeuction of transactions. Nothing has changed here except the idea that the developer might want to relax the ACID properties and take control of the transaction coordination, but this idea does not map well to existing TP infrastructure, which isn't going to change any time soon. Eric --- Gregg Wonderly <[EMAIL PROTECTED]> wrote: > Eric Newcomer wrote: > > Ok, thanks. You are right that I'm not familiar > with > > the Jini transaction implementation and this > sounds > > like something it would be good to know about. > > It's very capable 2 phase commit model. > > > What kind of transaction manager is available on > the > > phone? Is it capable of holding the transaction > root? > > What kind of resource manager is available on the > > phone? What happens in the Jini model when one of > the > > participants fails before acknowledging the commit > > message? > > The Jini model is that there is a service on the > network that is the transaction > manager for distributed transaction participants. > If the phone participates in > a transaction, the TransactionParticipant > implementation can be anywhere. As I > alluded to, its perfectly possible for the > transaction manager to use a > composite exporter that would export the normal Jini > end-point using JERI native > RPC, and then also export another end-point that > might be an HTTP service or > some other non-serialization based protocol. This > allows the phone to use a > lightweight protocol to participate. > > The phone, running Java J2ME, can serialize the > transaction ID onto the phones > backing store for persistence. Thus, it can > participate in the transaction > using disjoint sessions and just get the transaction > ID as needed. > > The lifecycle of the transaction participant is > based on leasing. The end-point > could provide the lease renewal management for the > disconnected client. At some > point, it could cancel the lease if the client > doesn't come back to complete the > transaction in a timely fashion (as you pass through > the tunnel :-). > > You can read the specifics of the commit progression > in the spec at > > <http://java.sun.com/products/jini/2.1/doc/specs/html/txn-spec.html> > > There's some solid logic in how things progress > around failures during commit. > It can make the participants job harder, but it > provides a much more resilent > system. > > > Does the Jini transaction manager support any > > standards, such as XA, JTS, or JTA? > > Not directly. These things can be easily interfaced > to in systems that have > such needs. The TransactionParticipant interface > > <http://java.sun.com/products/jini/2.1/doc/api/net/jini/core/transaction/server/TransactionParticipant.html> > > just needs to be implemented in a delegating > mechanism to interface into these > systems. > > These enterprise class transactional systems can > have quite a bit of overhead in > them. The Jini transaction model is aimed more > directly at lighter weight > transaction implementations which can provide for > more performant systems. > > Gregg Wonderly > > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
