RE: [JBoss-user] DB connection/transactions in the same J2EE transaction context.
I fucked up my backmerge from 3.0 to 2.4.3. Only 2.4.4(when it comes out), or Branch_2_4 synchs the database on a find or remove call. In 2.4.4 and 3.0, all beans of all types involved within a transaction will be synchronized with the database on a finder or remove call. Also, they will be synchronized in the same order in which they became part of the transaction. Please get latest from Branch_2_4 to get these changes. I'm sorry I screwed up the backmerge Regards, Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of danch > Sent: Friday, November 02, 2001 3:12 PM > To: David Jencks > Cc: [EMAIL PROTECTED] > Subject: Re: [JBoss-user] DB connection/transactions in the same J2EE > transaction context. > > > > > David Jencks wrote: > > > If you are depending on the changes being sent to the db in a certain > > order.. this may not be happening, I'm not sure. I think right > before the > > end of the transaction all ejbStore methods get called, but > perhaps not in > > any particular order. > > > > I believe that 2.4.3 has Bill's fix that forces ejbStores to be called > before any finder is called. Not in any specific order, however. > > -danch > > > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user > ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] DB connection/transactions in the same J2EE transaction context.
If this is the case, it should still work. The SLSB iterates through a list of business objects, finds there enterprise equivalent (findByPrimaryKey), sets the state and moves on to the next. Since the SLSB does not return before either saving all business object states or the first exception is thrown (i.e. TX rollback) A finder invokation would occur between each store. Unless I misunderstand what you are describing. To simplify this is the order of events. SLSB.saveBusinessObjects(List objs); for each obj in objs findEnterpriseEntity setEnterpriseEntityState end end The SLSB.saveBusinessObjects method has a tx attribute of Required as do all the state setters. All other methods use Supports. -Original Message- From: danch [mailto:[EMAIL PROTECTED]] Sent: Friday, November 02, 2001 3:12 PM To: David Jencks Cc: [EMAIL PROTECTED] Subject: Re: [JBoss-user] DB connection/transactions in the same J2EE transaction context. David Jencks wrote: > If you are depending on the changes being sent to the db in a certain > order.. this may not be happening, I'm not sure. I think right before the > end of the transaction all ejbStore methods get called, but perhaps not in > any particular order. > I believe that 2.4.3 has Bill's fix that forces ejbStores to be called before any finder is called. Not in any specific order, however. -danch ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user ** This e-mail contains privileged attorney-client communications and/or confidential information, and is only for the use by the intended recipient. Receipt by an unintended recipient does not constitute a waiver of any applicable privilege." Reading, disclosure, discussion, dissemination, distribution or copying of this information by anyone other than the intended recipient or his or her employees or agents is strictly prohibited. If you have received this communication in error, please immediately notify us and delete the original material from your computer." Sempra Energy Trading Corp. (SET) is not the same company as SDG&E or SoCalGas, the utilities owned by SET's parent company. SET is not regulated by the California Public Utilities Commission and you do not have to buy SET's products and services to continue to receive quality regulated service from the utilities." ** ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] DB connection/transactions in the same J2EE transaction context.
To add a little more information to this scenario. The connection pool is
using the oracle jdbc 1.1.1 driver using the
org.jboss.pool.jdbc.xa.wrapper.XADataSourceImpl wrapper for the DataSource.
(We have issues with the jdbc 1.2 driver not related to this)
We tested this scenario with just two business objects of the same class.
The first object created a side effect that the second business object
depended on. We put calls to a logging facility (not log4j) to provide a
detailed view of what was going on. The calls where ordered correctly.
However, the db connection instance was not the same when the second
persistance request was made.
Karl Koster
[EMAIL PROTECTED]
Sempra Energy Trading
203-355-5182
If you are depending on the changes being sent to the db in a certain
order.. this may not be happening, I'm not sure. I think right before the
end of the transaction all ejbStore methods get called, but perhaps not in
any particular order.
If you are using non xa connections ("local transactions" in the spec) then
jboss is in fact putting all the work on one transaction through one
connection - or it wouldn't be one transaction. With an xa capable driver,
it is not supposed to matter... which doesn't mean the driver is
implemented correctly.
david jencks
On 2001.11.02 14:06:29 -0500 Karl Koster wrote:
> I am hoping to find a simple resolution to this problem. I am running
> JBoss
> 2.4.3
>
> I have a SLSB that is used for persisting business objects implemented as
> simple java beans. These beans have "alter egos" as Entity Beans in the
> app
> server. (in fact, corresponding entity beans are simply facades for a
> copy
> of the java bean)
> The SLSB simply determines which class of Entity Bean to use, find it the
> instance nessecary, and set the underlying business object to that passed
> into the SLSB.
>
> The problem comes when passing a queue of business objects where later
> objects depend on side effects of the earlier objects within the
> database.
>
> According to the EJB 2.0 spec "The Bean Provider can control shareability
> of
> the connections acquired from the resource manager connection factory. By
> default, connections to a resource manager are shareable across other
> enterprise beans in the application that use the same resource in the
> same
> transaction context."
> "The sharing of connections to a resource manager allows the container to
> optimize the use of connections and enables the container's use of local
> transaction optimizations." (Section 20.4.1.1)
>
> From this I make the assumption (bad word I know) that, under a single
> (J2EE) transaction context, for the same resource, regardless of which
> instance of entity bean is being operated on, a connection will be
> re-used
> when requested more than once. I am not clear if this applies to multiple
> entity bean classes, since there references are in a difference
> namespace,
> but they do reference the same resource manager underneath everything.
>
> The following are snippets from my ejb-jar.xml and jboss.xml files:
>
> ejb-jar.xml
>
>
> jdbc/jts.Connection
> javax.sql.DataSource
> Container
> Sharable
>
>
> jboss.xml
>
>
> jdbc/jts.Connection
> jts.sempraDev
>
>
>
> jts.sempraDev
> java:/jts.sempraDev
>
>
> All of my beans have a trans-attribute of Required for all methods that
> affect the state of objects and a default of Supports for everything
> else.
>
> What appears to be happening is that there is no guaruntee that the same
> db
> connection will be used throughout the context of a single transaction,
> even
> within the same entity bean class. This is causing changes to be
> performed
> under one db transaction and subsequent changes that depend on the db
> side
> effects of the earlier changes to be performed under a seperate db
> transaction. The subsequent db transactions cannot see the earlier
> changes
> to the db and fail, rolling back the entire set of db transactions.
>
> When the business objects are submitted one at a time from the client
> everything works fine. It is only when a queue of business objects are
> submitted that the problem exists.
>
> From what I have understood about JBoss, this part of the EJB 2.0
> specification has been in place for some timel. Correct me if I am
> wrong.
>
> Any help/clarification would be appreciated.
>
> Karl Koster
> [EMAIL PROTECTED]
> Sempra Energy Trading
> 203-355-5182
>
>
>
> **
> This e-mail contains privileged attorney-client communications and/or
> confidential information, and is only for the use by the intended
> recipient. Receipt by an unintended recipient does not constitute a
> waiver of any applicable privilege."
>
> Reading, disclosure, discussion, dissemination, distribution or copying
> of this information by anyone other than the inte
Re: [JBoss-user] DB connection/transactions in the same J2EE transaction context.
David Jencks wrote: > If you are depending on the changes being sent to the db in a certain > order.. this may not be happening, I'm not sure. I think right before the > end of the transaction all ejbStore methods get called, but perhaps not in > any particular order. > I believe that 2.4.3 has Bill's fix that forces ejbStores to be called before any finder is called. Not in any specific order, however. -danch ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] DB connection/transactions in the same J2EE transaction context.
If you are depending on the changes being sent to the db in a certain
order.. this may not be happening, I'm not sure. I think right before the
end of the transaction all ejbStore methods get called, but perhaps not in
any particular order.
If you are using non xa connections ("local transactions" in the spec) then
jboss is in fact putting all the work on one transaction through one
connection - or it wouldn't be one transaction. With an xa capable driver,
it is not supposed to matter... which doesn't mean the driver is
implemented correctly.
david jencks
On 2001.11.02 14:06:29 -0500 Karl Koster wrote:
> I am hoping to find a simple resolution to this problem. I am running
> JBoss
> 2.4.3
>
> I have a SLSB that is used for persisting business objects implemented as
> simple java beans. These beans have "alter egos" as Entity Beans in the
> app
> server. (in fact, corresponding entity beans are simply facades for a
> copy
> of the java bean)
> The SLSB simply determines which class of Entity Bean to use, find it the
> instance nessecary, and set the underlying business object to that passed
> into the SLSB.
>
> The problem comes when passing a queue of business objects where later
> objects depend on side effects of the earlier objects within the
> database.
>
> According to the EJB 2.0 spec "The Bean Provider can control shareability
> of
> the connections acquired from the resource manager connection factory. By
> default, connections to a resource manager are shareable across other
> enterprise beans in the application that use the same resource in the
> same
> transaction context."
> "The sharing of connections to a resource manager allows the container to
> optimize the use of connections and enables the container's use of local
> transaction optimizations." (Section 20.4.1.1)
>
> From this I make the assumption (bad word I know) that, under a single
> (J2EE) transaction context, for the same resource, regardless of which
> instance of entity bean is being operated on, a connection will be
> re-used
> when requested more than once. I am not clear if this applies to multiple
> entity bean classes, since there references are in a difference
> namespace,
> but they do reference the same resource manager underneath everything.
>
> The following are snippets from my ejb-jar.xml and jboss.xml files:
>
> ejb-jar.xml
>
>
> jdbc/jts.Connection
> javax.sql.DataSource
> Container
> Sharable
>
>
> jboss.xml
>
>
> jdbc/jts.Connection
> jts.sempraDev
>
>
>
> jts.sempraDev
> java:/jts.sempraDev
>
>
> All of my beans have a trans-attribute of Required for all methods that
> affect the state of objects and a default of Supports for everything
> else.
>
> What appears to be happening is that there is no guaruntee that the same
> db
> connection will be used throughout the context of a single transaction,
> even
> within the same entity bean class. This is causing changes to be
> performed
> under one db transaction and subsequent changes that depend on the db
> side
> effects of the earlier changes to be performed under a seperate db
> transaction. The subsequent db transactions cannot see the earlier
> changes
> to the db and fail, rolling back the entire set of db transactions.
>
> When the business objects are submitted one at a time from the client
> everything works fine. It is only when a queue of business objects are
> submitted that the problem exists.
>
> From what I have understood about JBoss, this part of the EJB 2.0
> specification has been in place for some timel. Correct me if I am
> wrong.
>
> Any help/clarification would be appreciated.
>
> Karl Koster
> [EMAIL PROTECTED]
> Sempra Energy Trading
> 203-355-5182
>
>
>
> **
> This e-mail contains privileged attorney-client communications and/or
> confidential information, and is only for the use by the intended
> recipient. Receipt by an unintended recipient does not constitute a
> waiver of any applicable privilege."
>
> Reading, disclosure, discussion, dissemination, distribution or copying
> of this information by anyone other than the intended recipient or his or
> her employees or agents is strictly prohibited. If you have received
> this communication in error, please immediately notify us and delete the
> original material from your computer."
>
> Sempra Energy Trading Corp. (SET) is not the same company as SDG&E or
> SoCalGas, the utilities owned by SET's parent company. SET is not
> regulated by the California Public Utilities Commission and you do not
> have to buy SET's products and services to continue to receive quality
> regulated service from the utilities."
> **
>
>
> ___
> JBoss-user mailing list
> [EMAIL PROTECTED]
> https://lists.s
