Hi Thomas, let's suppose I want to use OJB with distributed BMT. In such a scenario, I guess I should do something like:
//* a generic SessionBean's method ... UserTransaction utx = sessionCtx.getUserTransaction(); utx.begin(); //* acquire transactional resources which will be enlisted in the current transaction //* these resources will be XAResources according to the XOpen/XA standard specification
... do work utx.commit(); ...
So, I am wondering how does OJB integrates itself in such a scenario. Which OJB classes can support me in coding something like that? I have downloaded your sources, but all the examples were involved with Container Managed Transaction, so I thought it was simply not possible to achieve distriuted BMT with OJB.
As in my previous mail, I repeat: I am a newbie to OJB, so maybe I am just missing something, but I need you to prove that I am wrong, for example pointing me out the classes I should better study and investigate to fully understand that I am really wrong.
-- ______________________________________________________ Francesco Russo DLAB - Datawarehouse Laboratory CINECA - Interuniversitary Computing Centre via Magnanelli, 6/3 40033 Casalecchio di Reno (Bologna) - ITALY e-mail: [EMAIL PROTECTED]
Thomas Mahler wrote:
Hi Francesco,
OJB provides support for JTA integration, so you should be able to use it in distributed BMT (and also CMT) environments.
Our JTA Mechanism works well with several J2EE containers and also Non J2EE-JTA implementation (as some CORBA ORB's with TransactionServer implementation)
I don't quite understand why you are talking about JCA in this context? JCA is not needed to work with distributed transactions.
Please read http://db.apache.org/ojb/deployment.html for more details.
Thomas
Francesco Russo wrote:
Hi everybody,
I was wondering whether OJB could be used in a managed enviroinment with distributed BMTs (Bean Managed Transactions) or not. In order to find an answer to my doubts, I downloaded the srcs and started to look for some useful clues and I didn't find anything stating the above scenario can be implemented, rather a hint that made me think it was not yet implemented (but planned for the future?).
That's what I found:
since, if I am not wrong, it is required to acquire a ManagedConnection from the Application Server implementation of the javax.resource.spi.ConnectionManager via a call to the allocateConnection(..., ...) method, I have searched for this call in the OJB srcs. As a result I got that the above call is issued only in two classes:
1. org.apache.ojb.otm.connector.JCAKit 2. org.apache.ojb.otm.connector.OTMConnectionManager
The former class calls the allocateConnection method over the latter one, so this entails that OJB provdes its own implementation of the javax.resource.spi.ConnectionManager, behaviour that is common to all those cases in which the application is outside a managed environment.
Question 1: why not relaying on the Application Server implementation of the ConnectionManager?
Furtheron, the javax.resource.spi.ManagedConnection returned as an org.apache.ojb.otm.connector.OTMJCAManagedConnection does not support the getXAResource() method, which is needed for enlisting the connections currently used by an application into the transactional context handled by the external TransactionManager according to the XOpen/XA Specification.
As I stated before, all these things made me think it is not possible to use BMTs along with OJB in managed environmet with distributed transaction, but possibily I'm just missing something, that's why I'm asking your help.
Any comments are appreciated
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- ______________________________________________________ Francesco Russo DLAB - Datawarehouse Laboratory CINECA - Interuniversitary Computing Centre via Magnanelli, 6/3 40033 Casalecchio di Reno (Bologna) - ITALY e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
