After reading your post a second time... I always assumed that what you are trying to do would work so never bothered figuring out whether or not the specs require it to.
In any case, jboss makes sure that any "connection" you get from the same datasource, enrolled in the same [user] transaction, will have the same view of the db as any other "connection" to the same db in the same tx. I know how this works in the jca framework (jboss 3 and using ConnectionFactoryLoader in jboss 2.4.x) and am confident it also works in the XADataSourceLoadeer/XADataSourceImpl code even though understanding it thoroughly is beyond my irrelevancy threshold. It is not clear to me if you have tried this on jboss and whether or not it is working for you. david jencks On 2002.03.21 14:25:13 -0500 bryan hansen wrote: > Thanks for the response, I was thinking something > along the lines of your response as to what the > problem might be. I guess the solution unfortunatly is > implementation specific if you try to break out the > database across two stateless session beans. This > would make some sense because if the stateless session > bean was calling a service on an entirly different > server it wouldn't be using the same connections. > > It would seem that this could be a very tricky problem > when trying to do aggregate ejbs. > > Thanks, > > Bryan > > --- Karl Koster <[EMAIL PROTECTED]> wrote: > > Bryan, > > > > I have come across this issue numerous times. The > > problem is that, according > > to the specification, no provision is made to share > > a DB connection in a > > transaction. Remember, the transaction the > > specification is speaking about > > is a container transaction not a DB transaction. The > > only thing the > > container guarantees is that the DB connection will > > not be used for another > > transaction (container or DB) until the container > > transaction finishes. > > > > Some containers allow you to share the DB connection > > to some degree. > > (Weblogic) But that is not a garantee that it will > > and is container > > specific. I don't believe JBoss currenly shares DB > > connections. > > > > Your best bet is to build local objects that can do > > the work entirely within > > a single bean's method call. > > > > Karl Koster > > [EMAIL PROTECTED] > > 203-355-5182 > > > > -----Original Message----- > > From: bryan hansen [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, March 21, 2002 9:24 AM > > To: [EMAIL PROTECTED] > > Subject: [JBoss-user] ejb foreign contsraints > > question > > > > > > I have a question as to if this will work in JBoss. > > I > > have tried this in IPlanet (which sucks) and it is > > not > > working, but I believe that it should. > > > > I have an statless session ejb that starts a user > > transaction called process. It then calls a statless > > session ejb named file that inserts some data into > > an > > oracle database. When finished with that the process > > ejb then calls a different stateless session bean > > named collateral. The collateral table has a foreign > > key constraint to the file table, but since this is > > in > > the same user transaction it has not written the > > data > > out to the file table to complete the foreign key > > constraint. > > > > I think that the container should handle this, but > > other people think otherwise. Any comments? > > Suggestions? I want to try this in JBoss, but > > haven't > > had the time to set it up and a database on a > > different machine. > > > > Thanks, > > > > Bryan > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Movies - coverage of the 74th Academy Awards® > > http://movies.yahoo.com/ > > > > _______________________________________________ > > 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." > > > ********************************************************************** > > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Movies - coverage of the 74th Academy Awards® > http://movies.yahoo.com/ > > _______________________________________________ > 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
