On Wed, 16 Feb 2011 20:51:34 -0200, Kalle Korhonen
<[email protected]> wrote:
On Wed, Feb 16, 2011 at 11:13 AM, Thiago H. de Paula Figueiredo
<[email protected]> wrote:
Shouldn't we have a proper transaction package and let it handle all
this?
What kind of features and functionality are you envisioning? Igor's
work seems to me like a step in the right direction and I don't have
time to participate so I am just happy that somebody's putting the
work in.
Something like Spring-TX, but using EJB3 annotations and implementing
transaction handling logic which isn't specific to a given database
technology. It would have a service (TransactionManager) which receives an
ordered configuration of TransactionHandlers (beforeInvocation(),
afterInvocation()), each one handling one of the transaction propagation
options (REQUIRES_NEW, REQUIRES, etc). We could provide support for just
some options at first and add more later. Another service interface,
TransactionPlatform, would deal with technology-specific transaction code
(beginTransaction(), commit(), rollback()). Tapestry-Hibernate would
provide a TransactionPlatform instance, Tapestry-JPA another, etc.
That's the basic idea: a transaction infrastructure that starts its life
simple, handling the common cases, which gets more complete with time and
need. :)
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
