On Thu, 2 Dec 1999 10:53:17 +0100, Stephane Boisson <[EMAIL PROTECTED]> wrote:
>Hi Dave,
>
>> 1) Lifecycle methods: ejbCreate, ejbPostCreate, ejbRemove
>> 2) Finder methods: findByPrimaryKey, etc.
>> 3) State management methods: ejbActivate, ejbPassivate, ejbLoad, ejbStore
>> (maybe state "synchronization" callbacks is a better term...)
>> 4) Business methods: getters, setters, other interesting behavior
>>
>> First, with the exception of #4, an entity bean's behavior is largely
>> oriented toward managing the persistent state of the "entity" and toward
>> locating the entity in persistent storage. In an ODBMS, we have alternate
>> ways of accomplishing these tasks that are often simpler.
>
>I don't know much about ODBMS, but are transactions managed like in EJB?
>Because transactions are a important part of EJB..
I can only speak for what I know of GemStone/J. Perhaps others who have
experience with other ODBMS products will chime in on this thread.
Yes, transactional methods of a session bean that manipulate GSJ-resident
domain objects would be using the GSJ EJB server's transaction management.
In GSJ, transactions utilize a CORBA Object Transaction Service (OTS)
which allows various sorts of resources (GemStone/J sessions, JDBC
connections) to participate in a coordinated, distributed transaction.
Examples are multiple GSJ sessions, JDBC connections and GSJ sessions,
or just JDBC connections.
When I want to commit a transaction involving objects living in the
GemStone database, I access those objects (resolve, bind) through a
GemStone session object (a GsSession). The GsSession is a transactional
resource, so it can participate in distributed transactions with a
JDBC connection (also a transactional resource).
In a scenario where say a session bean method modifies some persistent
objects that were accessed through a GsSession, the GemStone EJB container
takes care of causing those objects to be committed to the database.
If I also updated a relational database in my session bean method, then I
have a distributed transaction requiring a 2PC. Since JDBC 1.0 doesn't
provide for 2PC and some RDBMS vendors don't currently support 2PC, GSJ
can perform a "custom 2PC" (a.k.a. "1.5 phase commit") where if the RDB
commits successfully, then GemStone commits. Currently, in GSJ, any
number of JDBC connections pointing to the same data source can
participate in a distributed transaction (along with any number of
GsSessions).
Incidentally, the GemStone/J OTS can interoperate with other transaction
services that are compliant with the OMG OTS 1.1 specification, so a
client written with the third-party OTS can control GemStone/J
transactions. Similarly, a client written with the GemStone/J OTS can
control transactions that involve servers written with a third-party OTS.
So, client-demarcated transactions are supported.
Dave Muirhead
===========================================================================
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".
