Oops, I've been corrected that C is for Consistency.
-Chris.
"C is for Cookie", Cookie Monster.
> -----Original Message-----
> From: Chris Raber
> Sent: Monday, July 26, 1999 4:21 PM
> To: 'A mailing list for Enterprise JavaBeans development'
> Subject: RE: EJB transactions and multiple containers
>
> 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".
