Re: Container-managed Transactions scope

Rizwan wrote:

Thanks for reply.


It depends on the type of DB Connection you are using.  If you have
configured your DataSource to provide you with XA-based Connections, or
if it does so automatically, then you should be fine.


How can I know if my DataSource is configured for XA-based Connections or
does so automatically? I am using JBOSS 3.2.

Look at it's configuration. It is probably configured per server (as opposed to per application), though your application undoubtedly declares a reference to it in its deployment descriptor. Frankly, it's been a while since I mucked with JBoss configuration, but as I recall, in the servers I worked with the configuration information for each DataSource was in its own file in the server's filespace. I'm sorry I can't be more specific. To interpret the configuration information, you may also need documentation on the DB driver and/or some of the JBoss docs.

In my case I am working on now, only one JDBC connection (JNDI lookup) is

Do you mean that the Connection itself is stored and transferred via JNDI? That sounds like a recipe for disaster. Please tell me it's not what you meant. If your DAOs all want to use the same Connection (probably a good idea) then you should pass them a Connection to use as a parameter to each method that needs one. The normal role of JNDI in this scheme is to provide access to a shared DataSource object that your application uses to obtain Connections at need; I hope this is what you mean you're doing.

established for the whole transaction. The same connection is being used by
all concerned DAOs. The DAOs use this Connection to do their work but do not
perform any commit/rollback.

Here, perhaps, is a point that you do not yet appreciate: it is quite possible that your DAOs DO perform commits. This would happen on execution of each statement if the Connection is in autocommit mode. Now before you go running to turn off autocommit: don't. Mucking with the autocommit mode of a Connection is not allowed in EJB; you need to rely on the DataSource to give you correctly-configured Connections in the first place.

                              That will be the responsibility of my logical
unit of work. So for example I have a method updateEmployee() in a class
which updates 3 different tables and return 1 for success and -1 for
failure:
public int updateEmployee( Map parameterMap )
This method is being called from my EJB. This will be the semantics of this
method:
* Get a new Connection (JNDI lookup);
* Build DAO Factory and set it to use the Connection I have;
* Build DAOs from the DAO Factory (these DAOs recieve the Connection from
the DAO Factory)

OK, so this is a viable alternative to passing a Connection to each DAO method, though it does tie the Factory and all the DAO instances to a single transaction context. That's not necessarily a big deal, as it may fall out naturally that way anyway.

* Call 1st DAO's update method and get a return value.
* The return value is good. Call 2nd DAO's update method and get a return
value.
* The return value is not good. Now I want to rollback.

My question is how can I rollback or better should I issue a rollback for
the concerned connection or will the EJB takes care of it automatically?. If
I issue the rollback to the connection in DAO Factory then will my system
remain consistent with ACID?
Also if all 3 updates are good then should I issue a commit for the
concerned connection?

If you are using container-managed transactions (as you said you were), then to ensure rollback you invoke the setRollbackOnly() method of the bean's EJBContext. Supposing that you are using an XA Connection, it is my understanding that EJB takes care of rolling back the DB transaction upon exit from the transaction context, or for committing the DB transaction if it has not been marked for rollback. This would be my recommended mode of operation.

--
John Bollinger
jobollin@xxxxxxxxxxx
.

Relevant Pages

  • Re: How do you uniquely identify a connection in a connection pool
    ... Have you taken a look at the CLR Profiler? ... > will create as many as 25 new connections in the connection pool. ... the DAOs are in an assembly that is called by ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: DAOs and Connection sharing
    ... > same connection and transaction. ... > - Connection objects are not passed as method arguments. ... Have you looked at the Spring Framework? ... Framework manages the Datastore and DAOs nicely. ...
    (comp.lang.java.programmer)
  • Re: Container-managed Transactions scope
    ... In my case I am working on now, only one JDBC connection is ... The DAOs use this Connection to do their work but do not ... This method is being called from my EJB. ... >> the Container-managed Transactions be extended to the DAOs ...
    (comp.lang.java.programmer)
  • Re: How do you uniquely identify a connection in a connection pool
    ... Some approaches you can take to find which DAOs are not following the rules: ... Create a sql account and have it be the *only* account ... connection and you'll get an exception for those cases. ...
    (microsoft.public.dotnet.framework.adonet)
  • Windows Firewall with RAS (incoming connection)
    ... address on the LAN card and the Remote Desktop ... Connection to the SERVER can be established using that address. ... Windows IP Configuration ... Service configuration for Standard profile: ...
    (microsoft.public.windowsxp.work_remotely)