Re: questions on legacy transaction support
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
RE: questions on legacy transaction support
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
RE: questions on legacy transaction support
Knowing how the legacy handles transactions would help. Particulary interested if rollbacks are accomplished by 'compensating' transactions, which would make the whole process straightforward. JP -Original Message- From: Reason [mailto:[EMAIL PROTECTED]] Sent: Lunes, 24 de Septiembre de 2001 20:23 To: Orion-Interest Subject: questions on legacy transaction support 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/
