Re: Container-managed Transactions scope

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.

In my case I am working on now, only one JDBC connection (JNDI lookup) is
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. 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)
* 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?

Thanks



"John C. Bollinger" <jobollin@xxxxxxxxxxx> wrote in message
news:d6i5bd$ggg$1@xxxxxxxxxxxxxxxxxxxxxxxxxxx
> Rizwan wrote:
>
> > I work on stateless session EJBs which are using Container-managed
> > Transactions. My Inserts, Updates and Deletes are inside an EJB method.
I
> > never call any commit/rollback.
> >
> > Now i am starting to use DAO pattern. So Inserts, Updates and Deletes
are
> > available as DAO methods. Now the EJB calls the DAO methods to do this
kind
> > of stuff. The DAOs are not doing any commit/rollback. My question is
will
> > the Container-managed Transactions be extended to the DAOs
automatically.
> >
> > For example I have 3 updates as part of one transaction. These 3 updates
are
> > available in 3 different DAOs. If any one of them fail I want to
rollback
> > the whole transaction. Before when these 3 updates are inside EJB, I was
> > safe because of Container-managed Transactions. But now they are outside
of
> > EJB and I dont know if this functionality will be available.
> >
> > If container do keep track of transactions like that then how many
nested
> > levels I can go on? In one particular scenario, my EJB calls a method in
a
> > class which in turn calls DAOs for Inserts/Updates/Deletes. Will they be
> > part of Container-managed Transactions as well?
>
> 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. If not, then you
> are not fine, and probably never have been. In particular, if you have
> been using non-XA-based Connections with autocommit enabled then your DB
> transactions have always been finer-grained than your J2EE transactions,
> and you probably could not have correctly rolled back a J2EE transaction
> even if you had wanted to do. (Though you might not have received any
> exception.) You have a better chance of using non-XA Connections
> correctly with bean-managed transactions, but even there you would want
> to make sure that auto-commit was disabled, so that you could manually
> ensure that JDBC transaction boundaries lined up with J2EE boundaries,
> and that commit / rollback corresponded.
>
> --
> 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: 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)
  • Re: Container-managed Transactions scope
    ... 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. ... If your DAOs all want to use the same Connection then you should pass them a Connection to use as a parameter to each method that needs one. ...
    (comp.lang.java.programmer)
  • Re: Working Transactions somehow started not to work
    ... For the simple reason: transactions and locking involve ... Client-based cursors create their own ... the server-based cursors, hence from locking, hence from transactions. ... SL> Instead of using one of the connection created by Access, ...
    (microsoft.public.access.adp.sqlserver)