Eric,
It depends. If the beans are co-located in the same JVM, the EJB server will
most likely allocate the same JDBC resource to both beans (and therefor the
"in-flight" state will be shared), if the beans are not co-located, the JDBC
connection can not be shared, and therefor there will be multiple JDBC
transactions in play...
In general you shouldn't count on it, unless your EJB server lets you force
your beans to co-locate.
<vendor>
GemStone/J allows you flexibility to force beans to co-located when you need
to. This is the default deployment mode.
</vendor>
-Chris.
> -----Original Message-----
> From: Eric Williams [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, December 22, 1999 12:09 PM
> To: [EMAIL PROTECTED]
> Subject: Visibility of data modifications in multi-bean transaction
>
> 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".
===========================================================================
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".
