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
