Some clarifications below.
-Chris.
----------------------------------------------------------------------
Chris Raber, Systems Engineer, 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/
----------------------------------------------------------------------
> -----Original Message-----
> From: Chip Wilson [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, April 19, 1999 5:23 PM
> To: [EMAIL PROTECTED]
> Subject: Transactions and Bean Managed Persistence
>
> I have some questions on this subject.
>
> 1) In the spec, a phrase is often used, but I can find no definition for
> it.
> What does the phrase "this method will be called in the proper transaction
> context" mean? Specifically, does this statement imply that the method
> will
> always be called within a transaction?
>
It means there is an idea of a "current" transaction. I think of it as a
stack ( there can be
0 or more transaction contexts on the stack, but only the one closest to me
is current,
the others are suspended until the current transaction pops of the stack.
> 2) The sequence diagrams for entity beans with BMP show the underlying
> persistent store, represented by "database" on the diagram, registering
> itself with the same transaction service controlled by the
> javax.jts.UserTransaction. How can this be? My persistent store may be a
> legacy system that knows nothing about EJB, how could it know to register
> itself with the server's transaction mechanism?
>
Somehow the datastore is wrapped in a transaction resource, which can play
in
the 2PC architecture. EJB server/container vendors make this happening by:
- Wrapping JDBC 1.0 drivers with transaction resources
- Using JDBC drivers that are XA compatible
- Providing transaction resources to other datastores (e.g. GemStone's PCA)
Typically the vendor hooks the DriverManage.getConnection call to insert
a JDBC wrapper class that is transaction aware...
> 3) Let's say that I update two entity beans with BMP within the same
> transaction. I commit the transaction, and the container calls ejbStore
> on
> the first bean. This succeeds, and the container calls ejbStore on the
> second bean. During this call, the underlying persistent store rejects
> the
> update. Now, it would seem that there is no way to rollback the
> transaction. If the container calls ejbLoad on the first bean, it will
> load
> the data it just stored.
>
The ejbStore methods are called against beanswhich in term do IO to
transaction aware datastores ( the EJB server makes this so ). If the EJB
transaction rolls back, each underlying datastore is asked to rollback.
Since
the container knows the transaction has rolled back, it calls ejbLoad on the
beans to restore their state as necessary...
> Any help in understanding these issues would be appreciated.
>
> Chip Wilson
> ObjectSpace
>
> ==========================================================================
> =
> 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".
