You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Skip Walker <sk...@skipwalker.com> on 2002/01/14 17:33:19 UTC
Turbine and Transactions
This question is a best practices question.
How are users of Turbine dealing with actions where all or none transactions
would be desired?
For instance, I have an action that needs to add something to one of my
database tables, and then perform several operations on the turbine
user/security database tables. If one of these steps fail, then I would
like the whole action to fail, and roll back. This doesn't seem like a
unique problem, so I was wondering what kind of solutions people had.
Skip
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Turbine and Transactions
Posted by Scott Eade <se...@backstagetech.com.au>.
From: "Skip Walker" <sk...@skipwalker.com>
>
> I think the real root of my question was regarding how people are handling
> the need for transactions outside of the EJB environment. Are all
solutions
> homegrown?
Turbine includes facilities for handling transactions.
DBConnection dbCon = BasePeer.beginTransaction("default");
try {
objectA.save(dbCon);
objectB.save(dbCon);
BasePeer.commitTransaction(dbCon);
}
catch (SQLException ex) {
BasePeer.rollBackTransaction(dbCon);
}
An actual transaction will only be used if the underlying database
supports them.
HTH,
Scott
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Turbine and Transactions
Posted by Skip Walker <sk...@skipwalker.com>.
I think the real root of my question was regarding how people are handling
the need for transactions outside of the EJB environment. Are all solutions
homegrown?
> -----Original Message-----
> From: Scott Eade [mailto:seade@backstagetech.com.au]
> Sent: Monday, January 14, 2002 3:10 PM
> To: Turbine Users List
> Subject: Re: Turbine and Transactions
>
>
> From: "Skip Walker" <sk...@skipwalker.com>
> >
> > This question is a best practices question.
> >
> > How are users of Turbine dealing with actions where all or none
> transactions
> > would be desired?
> >
> > For instance, I have an action that needs to add something
> to one of my
> > database tables, and then perform several operations on the turbine
> > user/security database tables. If one of these steps fail,
> then I would
> > like the whole action to fail, and roll back. This doesn't
> seem like a
> > unique problem, so I was wondering what kind of solutions
> people had.
>
> The current security implementation does not use
> transactions. I still
> haven't got around to posting my hack/patch to overcome the problem
> highlighted in the extend-user-howto, but further work is necessary to
> enable transactions.
>
> >
> > Skip
> >
>
> Scott
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Turbine and Transactions
Posted by Scott Eade <se...@backstagetech.com.au>.
From: "Skip Walker" <sk...@skipwalker.com>
>
> This question is a best practices question.
>
> How are users of Turbine dealing with actions where all or none
transactions
> would be desired?
>
> For instance, I have an action that needs to add something to one of my
> database tables, and then perform several operations on the turbine
> user/security database tables. If one of these steps fail, then I would
> like the whole action to fail, and roll back. This doesn't seem like a
> unique problem, so I was wondering what kind of solutions people had.
The current security implementation does not use transactions. I still
haven't got around to posting my hack/patch to overcome the problem
highlighted in the extend-user-howto, but further work is necessary to
enable transactions.
>
> Skip
>
Scott
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>