Mark,
I'll try to give a vendor' perspective on this.
> -----Original Message-----
> From: Mark Feblowitz [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, July 19, 1999 2:49 PM
> To: [EMAIL PROTECTED]
> Subject: EJB transactions and multiple containers
>
> 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 one that starts the transaction.
> 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.
>
This will work if the vendors use a common underlying transaction protocol.
In GemStone/J we chose to build our transaction servive using CORBA
CosTransaction for this reason. Many other EJB servers are also using
CosTransaction. Interoperability between these containers is very possible,
but of course the devil is in the details. Vendors will be driven by market
interest in this requirement.
> If not defined in the specification, are there vendors that are
> solving this problem? How are they doing this?
>
Using CORBA as the basis is a good start. Interop at the EJB level needs to
be proven, but is theoretically very doable.
> Can CORBA objects participate in transactions coordinated by an EJB
> Server? Can EJB components participate in transactions coordinated on
> the CORBA side?
>
This is the case with GemStone/J, and likely the case with other EJB servers
that are CosTransaction based.
> 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?
>
Atomicity - The global transaction provides atomicity at the distributed
transaction level. Resources participating in the transaction are under
contract to do so at the resource level (e.g. JDBC transactions).
Concurrency - This is the responsibility of the underlying transactional
resource (e.g. JDBC connection).
Isolation - This is the responsibility of the underlying transactional
resource (e.g. JDBC connection).
Durability - This is the responsibility of the underlying transactional
resource (e.g. JDBC connection).
So the transaction manager in concert with the underlying resource managers
together provide for ACID.
-Chris.
----------------------------------------------------------------------
Chris Raber, Director Professional Services, GemStone Systems Inc.
100 West Big Beaver, Suite 200, Troy, MI 48084
phone: (248)-680-6691, fax: (248)-680-6689,
email: [EMAIL PROTECTED]
web: http://www.gemstone.com/
----------------------------------------------------------------------
> Mark
>
> _______________________________________________________________________
> Mark Feblowitz 40 Sylvan Road
> Senior Principal Member of Technical Staff Waltham, MA 02451-1128
> GTE Laboratories Incorporated [EMAIL PROTECTED]
> (617) 466-2947, fax (617) 466-2618
>
> ==========================================================================
> =
> 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".
===========================================================================
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".
