ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James, Steven" <Steven.Ja...@logicacmg.com>
Subject FW: ibatis and global transactions
Date Mon, 23 May 2005 09:23:31 GMT
 thanks brandon and rafiq. this is the route i will now explore. Ibatis 
is a fine product but the support on the forums here makes it something else.

top job.

Steve..


-----Original Message-----
From: Brandon Goodin [mailto:brandon.goodin@gmail.com]
Sent: Fri 5/20/2005 6:33 PM
To: James, Steven
Subject: Re: ibatis and global transactions
 
I believe EXTERNAL would be the way for you to go. If you are making
changes against your database that are not completed all at once in a
single connection then you would have to devise a strategy outside of
ibatis to manage that.

Standard IBatis works something like this.

User Data passed to Biz Logic -> Biz Logic calls dao(s) -> sql is
prepared -> connection is retrieved -> operation is executed ->
connection is closed -> results are passed back to biz logic via dao
-> data presented to user.

In your scenario you would need to retain the connection for the user
in order to prevent a commit. This would require that you manage you
own connection externally and pass them in to ibatis. You will also
need a way to manage your connections and identify them with the
users. But, i suspect you know how to do that.

Brandon



On 5/20/05, James, Steven <Steven.James@logicacmg.com> wrote:
> Thanks brandon.
> I think i may have used the term global transaction incorrectly.
> I really would like to have a unit or work start, end transaction that spans a
> number of business objects and can be rolled back at client request. I will also only
have one datasource.
> Also i do not use the ibatis daomanager i created a simple class that gets my dao.
> 
> If your original response is correct can i use jta without jndi.
> Again thanks for you help it is most appriciated.
> 
> steve...
> 
> -----Original Message-----
> From: Brandon Goodin [mailto:brandon.goodin@gmail.com]
> Sent: Fri 5/20/2005 2:19 PM
> To: ibatis-user-java@incubator.apache.org
> Subject: Re: ibatis and global transactions
> 
> You can manage your transactions with EXTERNAL of JTA. I believe that
> EXTERNAL is the better route to go in this case. This means that you
> will need to configure and manually start and stop your transactions
> outside of ibatis. Search the DAO pdf doc and the SQL Maps pdf doc for
> external to get more information.
> 
> The JTA option in ibatis is tied to a single datasource. So, as far as
> global transactions that span databases... I don't think it would be
> that simple to accomplish with iBatis JTA support.
> 
> Your other option is to use Spring (which would mean you get rid of
> the dao.xml) and setup sqlMapConfigs for each database you are
> accessing. Then you could use Spring's transaction management to
> manage transactions across any data access implementations you might
> have.
> 
> Brandon
> 
> On 5/20/05, James, Steven <Steven.James@logicacmg.com> wrote:
> > Hi
> >
> > I working on an application where the services and buisness domain objects are sitting
on a server with ibatis providing the data access layer support.
> > The clients which are swt client connect to the server and via rpc calls.
> > Our customer want us to rollback all db changes during a user login should they
not want to commit (Commit in our case is not commit to db but to cascade data changes to
other machines) ie they want to undo the changes made to the db ie rollback. Is ibatis capable
of providing this global transaction that spans a users session if you like.
> >
> > In the daomanager api there is talk of 2 phase commits but i dont think this is
the same thing?
> >
> > we are using mysql and the jdbc connector 3.1.6, the jdk is 1.4.2 no j2ee application
server.
> >
> > many thanks
> >
> > steve..
> >
> > This e-mail and any attachment is for authorised use by the intended recipient(s)
only. It may contain proprietary material, confidential information and/or be subject to legal
privilege. It should not be copied, disclosed to, retained or used by, any other party. If
you are not an intended recipient then please promptly delete this e-mail and any attachment
and all copies and inform the sender. Thank you.
> >
> 
> 
> This e-mail and any attachment is for authorised use by the intended recipient(s) only.
It may contain proprietary material, confidential information and/or be subject to legal privilege.
It should not be copied, disclosed to, retained or used by, any other party. If you are not
an intended recipient then please promptly delete this e-mail and any attachment and all copies
and inform the sender. Thank you.
>



This e-mail and any attachment is for authorised use by the intended recipient(s) only. It
may contain proprietary material, confidential information and/or be subject to legal privilege.
It should not be copied, disclosed to, retained or used by, any other party. If you are not
an intended recipient then please promptly delete this e-mail and any attachment and all copies
and inform the sender. Thank you.

Mime
View raw message