ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric T. Blue" <ericblu...@gmail.com>
Subject Re: Help with understanding transaction behavior with multiple threads
Date Wed, 21 Jun 2006 05:37:30 GMT
Brandon,

Sorry for the delayed response, I just got back from vacation.  I expected
Clinton's response to be the case, and appreciate the honesty ;)  I suppose
the best solution right now is for me to re-architect how and where the
transaction begins and make sure it is started by my worker thread.  The
short answer is that we have a facade in front of our web service tier that
is responsible for handling transactions.  e.g.  Facade (starts/ends
transactions)-> Service Layer (using threads) -> DAOs.  One reason why we
chose to handle the threaded unit of work in the service layer is to allow
other sessions to terminate existing units of work, and thereby rollback any
changes that were in progress.  One approach is for me to make an expection
to our normal convention and more the responsibility of transactionalization
down to the service layer.  But, I am more curious if there are other
recommended strategies, best practices, or technologies for doing this.
Thanks for your help.

On 6/10/06, Brandon Goodin <brandon.goodin@gmail.com> wrote:
>
> Eric,
>
> If you can tell us "why" you are doing what you are doing perhaps we
> can assist you in providing some suggestions on how it can be
> accomplished.
>
> Brandon
>
> On 6/9/06, Clinton Begin <clinton.begin@gmail.com> wrote:
> >
> > Fortunately the answer is simple, unfortunately you're probably not
> going to
> > like it. :-)
> >
> > NEVER cross thread boundaries within (what you expect to be) a single
> > transaction.  Never.
> >
> > Cheers,
> > Clinton
> >
> >
> >
> > On 6/5/06, Eric T. Blue <ericblue76@gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > I want to find out the easiest possible way to start a transaction,
> create
> > a thread that performs DAO inserts, and still have the newly created
> thread
> > honor the start and end transaction from the launching application.
> > >
> > > I'm working on a project where I'm using iBatis DAO with SQLMAP as my
> > transaction manager.  Up until this point transactions and rollbacks
> work
> > fine.
> > >
> > > daoManager.startTransaction();
> > >
> > > try {
> > >     service.createObject (a);
> > >
> > >     daoManager.commitTransaction();
> > >
> > > } catch (ServiceException e) {
> > >     // Handle exception
> > > } finally {
> > >
> > >     daoManager.endTransaction();
> > > }
> > >
> > > I now have a situation where instead of calling service.createObject()
> > directly I'm creating an encapsulated unit of work and running with a
> new
> > thread.  What I've discovered is that whenever an exception is thrown,
> the
> > create Object exists in the database, although commitTransaction has
> never
> > been called.  After browsing through the mailing list, and eventually
> the
> > code, I discovered that the dao manager (DaoContext) is using
> ThreadLocal to
> > keep track of transaction and state.  Given this fact, is it even
> possible
> > to solve my problem without having to change the underlying code or
> right
> > some sort of wrapper class.
> > >
> > > What I'm a little confused about is that default autocommit is set to
> > false.  If the launched thread performs the INSERT, even though it is
> > unaware that start transaction and end transaction are happening, why is
> the
> > record being committed?  Any help would be appreciated.
> > >
> >
> >
>

Mime
View raw message