I have read through both the EJB 1.0 and 1.1 specifications, and I can't
find an answer to whether "in flight" transactional state is visible
from one bean call to another.
Suppose I have two stateless session beans, BeanA and BeanB. Both have
the "Requires" transaction attribute. The client calls a method on
BeanA. BeanA then calls a method on BeanB. What I'd like to know is if
BeanB has visibility to the in-flight transaction modifications made by
BeanA. For example:
BeanA.foo() {
// initially, account 123's balance is 500.
// get the DataSource
// get a java.sql.Connection
// UPDATE account SET balance = balance + 100 WHERE acct_id=123
// now account 123's balance is 600.
// obtain a reference to BeanB's EJB object
bean_b.bar();
}
BeanB.bar() {
// get the DataSource
// get a java.sql.Connection
// SELECT acct_id, balance FROM account WHERE acct_id=123
// what is account 123's balance? 500 or 600?
}
Since both beans have the Requires transaction attribute, a transaction
will be started by the container when BeanA.foo() is invoked. BeanA
obtains a transactional resource (in this case a JDBC connection) and
modifies some data. BeanA then calls BeanB (not directly, but through
the EJBObject). When BeanB.bar() is invoked, the container does not
start a new transaction, because the call was already made in a
transaction context. BeanB then makes a query for data.
But the data BeanB is querying is data that was modified by BeanA. Are
the changes made by BeanA visible to BeanB? Will BeanB see the updated
account balance or not?
Further, if BeanA and BeanB are executing in the same process, will the
java.sql.Connection returned by the DataSource in BeanB.bar() be the
same Connection object that is being used by BeanA?
What are the semantics if BeanA and BeanB are running in different
processes?
Did I just miss this information in the EJB 1.1 spec? Or is the spec
intentionally vague about this. It seems to me that these semantics
should be well specified (or at least identified as vague and
non-portable). The EJB 1.1 section on "diamond" transaction scenarios
comes close, but doesn't fully address the issue. In the scenario
documented in this email, the account state is not cached... but instead
is stored in a transactional resource.
-eric
===========================================================================
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".
