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/ > >
