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 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/
