Mark, I think you can find answers to many of your questions in the JTS Spec, but I
try to answer them anyway...
>We would like to understand whether the EJB specification
>defines/supports/prohibits transactions that cross container
>boundaries, and, if so, how such transactions are coordinated. If a
>transaction can span multiple containers/servers, which
>container/server is considered to be the Transaction Coordinator?
The container where the transaction started. (and you can only terminate the
transaction from the same JVM as the transaction originator.)
>We would also like to know whether such transactions could be carried
>out among containers provided by multiple vendors, and what protocol
>they would use to coordinate such transactions.
>If not defined in the specification, are there vendors that are
>solving this problem? How are they doing this?
I think it *is* defined (in the JTS spec). The answer is OTS. Take a look at
org.omg.CosTransactions and org.omg.CosTSPortability. I cannot say if there are any
success for inter-ORB interoperability today. (I guess we hear from the vendors if it
exist :-) )
>Can CORBA objects participate in transactions coordinated by an EJB
>Server? Can EJB components participate in transactions coordinated on
>the CORBA side?
According to the JTS spec it is optional to support CORBA application entities, i.e.
Transactional Client, Recoverable Object, and so on. These entites use the interfaces
defines in the CosTransaction module in that case. (So if you have access to the same
transaction manager and uses the transaction manager directly from the CORBA object I
guess it could work.)
>Which of the ACID transaction properties are being (can be)
>preserved/guaranteed for global transactions (within a container and
>across container boundaries), given that serializability of local
>transactions doesn't imply serializability of global transactions? We
>know that atomicity is easy to achieve (via the two-phase commit
>protocol) - what about the other properties?
According to the JTS spec (again) the transaction manager must guarantee the checked
transaction behavior, which means the transaction manager has to be sure that all the
work has been completed for all the XA resources participating in the global
transaction. This guarantees the transaction integrity. But the question is still
there. Which of the properties are being preserved? I think atomicity, isolation and
durability can be preserved, but how about Consistency?
Hope this helps
/Tommy
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
