Thanks. I'll give it a try and see what happens. If anyone here can verify
that the same UserTransaction instance is in fact associated with a
transaction for its entire lifetime, that would be useful.
Reason
http://www.exratio.com/
--> Stephen Davidson
> Hi Reason.
>
> I was hoping somebody on the list would respond sooner with known
> reliable information.
>
> I would suggest (b). I am doing distributed transactions over
> (potentially) multiple servers using multiple EJBs. This seems to be
> working for me (initial tests are ok). However, the code is in Alpha
> release, and has not seen serious stress levels, or been placed in
> production. So I can't verify yet how well this will work once
> thousands of users start hitting it.
>
> Good Luck,
> Steve
>
>
> Reason wrote:
> >
> > I'm attempting to use Orion pretty much for the easy custom
> authentication/user management and very little else. That all
> works pretty well -- as an ex-JBoss user, let me say that I like
> the straightforward approach.
> >
> > So I have a bunch of BMP beans that wrap some legacy software.
> The legacy software comes complete with legacy transactions and
> I'm trying to figure out the best way to deal with this such that:
> >
> > 1) I can reliably pick up the right legacy transaction at the
> right time in my bean methods
> >
> > 2) a given user can have more than one transaction on the go at
> once in separate threads
> >
> > Now, I can write any old middle layer I choose to associate
> specific legacy transactions with some object/value/concept from
> the EJB layer (in a hashtable, for example), but I don't have a
> good enough grasp on the Orion container to figure out which of
> the following items are going to be constants between different
> threads or method calls to the server:
> >
> > a) EJBContext (EntityContext, SessionContext): these would seem
> to be out of consideration, as they are reused between beans and
> threads, and a transaction might extend throughout several method
> calls in both session and entity beans.
> >
> > b) UserTransaction: I could associate a UserTransaction
> instance with a legacy transaction instance. If I start a
> transaction in a session bean, which then calls entity bean
> methods, is the same UserTransaction instance going to result
> from calls to context.getUserTransaction() in the contexts for
> the various beans?
> >
> > c) Principal name: I could associate a legacy transaction with
> a principal name if not for wanting to allow each principal the
> option of multiple concurrent transactions in different threads.
> >
> > d) Thread: a legacy transaction could be associated with a
> specific server thread. Is this going to work? Are
> UserTransactions associated with a specific thread throughout
> their lifetime? Is this thread the same thread that is used for
> separate method calls that fall within the transaction?
> >
> > So, any suggestions or ideas from the list on this one?
> >
> > Reason
> > http://www.exratio.com/
>
> --
> Stephen Davidson
> Java Consultant
> Delphi Consultants, LLC
> http://www.delphis.com
> Phone: 214-696-6224 x208
