You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Igor Drobiazko <ig...@gmail.com> on 2011/02/16 17:44:31 UTC
JPA: Committing transactions
Hi all,
as you probably know I'm working on the Tapestry/JPA integration. In
contrast to Tynamo's integration, Tapestry's built-in JPA support will allow
having several persistence units in an application. This way you can inject
several EntityManagers into a single page, which are connected to different
databases.
public class PersistEntity
{
@PersistenceUnit(unitName = "TestUnit")
private EntityManager em;
@PersistenceUnit(unitName = "AnotherUnit")
private EntityManager em2;
@CommitAfter
void onSuccess() {
.....
}
}
Now I have some issues to apply Tapestry's @CommitAfter semantics to JPA
resource-local transactions. With Hibernate you have a single Session, so it
is clear what to commit when @CommitAfter annotation is present: the active
transaction of the single session. With JPA you can have several
EntityManagers and so several transactions. When @CommitAfter is present,
you don't know which of the active transactions to commit.
So, the questions is what would be the best solution? Committing all the
active transactions? Maybe we could add a new attribute to @CommitAfter
annotations, which expects a list of persistence unit names to commit the
transactions of?
@CommitAfter( { "TestUnit", "AnotherUnit" } )
void onSuccess() {
.....
}
Any thoughts or ideas`?
--
Best regards,
Igor Drobiazko
http://tapestry5.de
Re: JPA: Committing transactions
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Thu, 17 Feb 2011 06:14:29 -0200, Igor Drobiazko
<ig...@gmail.com> wrote:
> I'm not sure if such a module is what Tapestry needs to cover.
Why not? This is something IoC packages end up implementing. I guess there
are some people using Spring with Tapestry 5 just for the transaction
management and they would be more than happy to get rid of Spring. I'm one
of them.
> However, if we decide to provide such a module, I don't see it in T5.3.
> Right now I
> would like to concentrate on plain JPA support, which can be extended
> by a transaction module later.
Agreed.
--
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: JPA: Committing transactions
Posted by Igor Drobiazko <ig...@gmail.com>.
I'm not sure if such a module is what Tapestry needs to cover. However, if
we decide to provide such a module, I don't see it in T5.3. Right now I
would like to concentrate on plain JPA support, which can be extended by a
transaction module later.
On Thu, Feb 17, 2011 at 12:16 AM, Thiago H. de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> On Wed, 16 Feb 2011 20:51:34 -0200, Kalle Korhonen <
> kalle.o.korhonen@gmail.com> wrote:
>
> On Wed, Feb 16, 2011 at 11:13 AM, Thiago H. de Paula Figueiredo
>> <th...@gmail.com> 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Best regards,
Igor Drobiazko
http://tapestry5.de
Re: JPA: Committing transactions
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Wed, 16 Feb 2011 20:51:34 -0200, Kalle Korhonen
<ka...@gmail.com> wrote:
> On Wed, Feb 16, 2011 at 11:13 AM, Thiago H. de Paula Figueiredo
> <th...@gmail.com> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: JPA: Committing transactions
Posted by Kalle Korhonen <ka...@gmail.com>.
On Wed, Feb 16, 2011 at 11:13 AM, Thiago H. de Paula Figueiredo
<th...@gmail.com> 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.
Kalle
> On Wed, 16 Feb 2011 16:39:41 -0200, Josh Canfield <jo...@gmail.com>
> wrote:
>
>>> Well, @PersistenceUnit annotation has unitName attribute, which is used
>>> to
>>> idenity the unit specified in persistence.xml.
>>
>> Ah. I don't use JPA.
>>
>>> But the current
>>> questions is not how to identify the units but whether we want to commit
>>> all
>>> transactions at once.
>>
>> Perhaps by default @CommitAfter should commit everything, and if you
>> want to limit it you provide appropriate @PersistenceUnit
>> on the onSuccess method.
>>
>> How are you going to deal with failures when doing a multi-unit commit?
>>
>> Josh
>>
>> On Wed, Feb 16, 2011 at 10:02 AM, Igor Drobiazko
>> <ig...@gmail.com> wrote:
>>>
>>> Well, @PersistenceUnit annotation has unitName attribute, which is used
>>> to
>>> idenity the unit specified in persistence.xml.
>>>
>>>
>>> http://download.oracle.com/javaee/6/api/javax/persistence/PersistenceUnit.html
>>>
>>> First I would concentrate on the standard way to indentify the units;
>>> namely
>>> by string names. Later we can think about using annotations. But the
>>> current
>>> questions is not how to identify the units but whether we want to commit
>>> all
>>> transactions at once.
>>>
>>> On Wed, Feb 16, 2011 at 6:02 PM, Josh Canfield
>>> <jo...@gmail.com>wrote:
>>>
>>>> Can you do this with marker annotations instead?
>>>> @PersistenceUnit
>>>> @MyTestUnit
>>>> private EntityManager em;
>>>>
>>>> @PersistenceUnit
>>>> @MyOtherUnit
>>>> private EntityManager em2;
>>>>
>>>> @CommitAfter
>>>> @MyOtherUnit
>>>> @MyTestUnit // commit them both
>>>> void onSuccess() {...}
>>>>
>>>> If you recall Tom van Dijk did a lot of work getting multiple
>>>> hibernate sessions to work. Have you looked at his additions?
>>>> http://codereview.appspot.com/2896041/
>>>>
>>>> There is an email floating around with access to his git repository
>>>> and discussing issues of CommitAfter, etc.
>>>>
>>>> Josh
>>>>
>>>> On Wed, Feb 16, 2011 at 8:44 AM, Igor Drobiazko
>>>> <ig...@gmail.com> wrote:
>>>> > Hi all,
>>>> >
>>>> > as you probably know I'm working on the Tapestry/JPA integration. In
>>>> > contrast to Tynamo's integration, Tapestry's built-in JPA support will
>>>> allow
>>>> > having several persistence units in an application. This way you can
>>>> inject
>>>> > several EntityManagers into a single page, which are connected to
>>>> different
>>>> > databases.
>>>> >
>>>> > public class PersistEntity
>>>> > {
>>>> > @PersistenceUnit(unitName = "TestUnit")
>>>> > private EntityManager em;
>>>> >
>>>> > @PersistenceUnit(unitName = "AnotherUnit")
>>>> > private EntityManager em2;
>>>> >
>>>> >
>>>> > @CommitAfter
>>>> > void onSuccess() {
>>>> >
>>>> > .....
>>>> > }
>>>> > }
>>>> >
>>>> > Now I have some issues to apply Tapestry's @CommitAfter semantics to
>>>> > JPA
>>>> > resource-local transactions. With Hibernate you have a single Session,
>>>> > so
>>>> it
>>>> > is clear what to commit when @CommitAfter annotation is present: the
>>>> active
>>>> > transaction of the single session. With JPA you can have several
>>>> > EntityManagers and so several transactions. When @CommitAfter is
>>>> > present,
>>>> > you don't know which of the active transactions to commit.
>>>> >
>>>> > So, the questions is what would be the best solution? Committing all
>>>> > the
>>>> > active transactions? Maybe we could add a new attribute to
>>>> > @CommitAfter
>>>> > annotations, which expects a list of persistence unit names to commit
>>>> > the
>>>> > transactions of?
>>>> >
>>>> > @CommitAfter( { "TestUnit", "AnotherUnit" } )
>>>> > void onSuccess() {
>>>> >
>>>> > .....
>>>> > }
>>>> >
>>>> >
>>>> > Any thoughts or ideas`?
>>>> >
>>>> > --
>>>> > Best regards,
>>>> >
>>>> > Igor Drobiazko
>>>> > http://tapestry5.de
>>>> >
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> Best regards,
>>>
>>> Igor Drobiazko
>>> http://tapestry5.de
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and
> instructor
> Owner, Ars Machina Tecnologia da Informação Ltda.
> Consultor, desenvolvedor e instrutor em Java, Tapestry e Hibernate
> Coordenador e professor da Especialização em Engenharia de Software com
> Ênfase em Java da Faculdade Pitágoras
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: JPA: Committing transactions
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Shouldn't we have a proper transaction package and let it handle all this?
On Wed, 16 Feb 2011 16:39:41 -0200, Josh Canfield <jo...@gmail.com>
wrote:
>> Well, @PersistenceUnit annotation has unitName attribute, which is used
>> to
>> idenity the unit specified in persistence.xml.
>
> Ah. I don't use JPA.
>
>> But the current
>> questions is not how to identify the units but whether we want to
>> commit all
>> transactions at once.
>
> Perhaps by default @CommitAfter should commit everything, and if you
> want to limit it you provide appropriate @PersistenceUnit
> on the onSuccess method.
>
> How are you going to deal with failures when doing a multi-unit commit?
>
> Josh
>
> On Wed, Feb 16, 2011 at 10:02 AM, Igor Drobiazko
> <ig...@gmail.com> wrote:
>> Well, @PersistenceUnit annotation has unitName attribute, which is used
>> to
>> idenity the unit specified in persistence.xml.
>>
>> http://download.oracle.com/javaee/6/api/javax/persistence/PersistenceUnit.html
>>
>> First I would concentrate on the standard way to indentify the units;
>> namely
>> by string names. Later we can think about using annotations. But the
>> current
>> questions is not how to identify the units but whether we want to
>> commit all
>> transactions at once.
>>
>> On Wed, Feb 16, 2011 at 6:02 PM, Josh Canfield
>> <jo...@gmail.com>wrote:
>>
>>> Can you do this with marker annotations instead?
>>> @PersistenceUnit
>>> @MyTestUnit
>>> private EntityManager em;
>>>
>>> @PersistenceUnit
>>> @MyOtherUnit
>>> private EntityManager em2;
>>>
>>> @CommitAfter
>>> @MyOtherUnit
>>> @MyTestUnit // commit them both
>>> void onSuccess() {...}
>>>
>>> If you recall Tom van Dijk did a lot of work getting multiple
>>> hibernate sessions to work. Have you looked at his additions?
>>> http://codereview.appspot.com/2896041/
>>>
>>> There is an email floating around with access to his git repository
>>> and discussing issues of CommitAfter, etc.
>>>
>>> Josh
>>>
>>> On Wed, Feb 16, 2011 at 8:44 AM, Igor Drobiazko
>>> <ig...@gmail.com> wrote:
>>> > Hi all,
>>> >
>>> > as you probably know I'm working on the Tapestry/JPA integration. In
>>> > contrast to Tynamo's integration, Tapestry's built-in JPA support
>>> will
>>> allow
>>> > having several persistence units in an application. This way you can
>>> inject
>>> > several EntityManagers into a single page, which are connected to
>>> different
>>> > databases.
>>> >
>>> > public class PersistEntity
>>> > {
>>> > @PersistenceUnit(unitName = "TestUnit")
>>> > private EntityManager em;
>>> >
>>> > @PersistenceUnit(unitName = "AnotherUnit")
>>> > private EntityManager em2;
>>> >
>>> >
>>> > @CommitAfter
>>> > void onSuccess() {
>>> >
>>> > .....
>>> > }
>>> > }
>>> >
>>> > Now I have some issues to apply Tapestry's @CommitAfter semantics to
>>> JPA
>>> > resource-local transactions. With Hibernate you have a single
>>> Session, so
>>> it
>>> > is clear what to commit when @CommitAfter annotation is present: the
>>> active
>>> > transaction of the single session. With JPA you can have several
>>> > EntityManagers and so several transactions. When @CommitAfter is
>>> present,
>>> > you don't know which of the active transactions to commit.
>>> >
>>> > So, the questions is what would be the best solution? Committing all
>>> the
>>> > active transactions? Maybe we could add a new attribute to
>>> @CommitAfter
>>> > annotations, which expects a list of persistence unit names to
>>> commit the
>>> > transactions of?
>>> >
>>> > @CommitAfter( { "TestUnit", "AnotherUnit" } )
>>> > void onSuccess() {
>>> >
>>> > .....
>>> > }
>>> >
>>> >
>>> > Any thoughts or ideas`?
>>> >
>>> > --
>>> > Best regards,
>>> >
>>> > Igor Drobiazko
>>> > http://tapestry5.de
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>
>>>
>>
>>
>> --
>> Best regards,
>>
>> Igor Drobiazko
>> http://tapestry5.de
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
Consultor, desenvolvedor e instrutor em Java, Tapestry e Hibernate
Coordenador e professor da Especialização em Engenharia de Software com
Ênfase em Java da Faculdade Pitágoras
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: JPA: Committing transactions
Posted by Dmitry Gusev <dm...@gmail.com>.
On Thu, Feb 17, 2011 at 11:24, Igor Drobiazko <ig...@gmail.com>wrote:
> On Wed, Feb 16, 2011 at 7:39 PM, Josh Canfield <joshcanfield@gmail.com
> >wrote:
>
> >
> >
> > How are you going to deal with failures when doing a multi-unit commit?
> >
> >
> This is the big question. As EntityTransaction doesn't support 2-phase
> commit, you can have a corrupt state in case of failures when doing a
> multi-unit commit.
>
>
> Here is for example what Seam doc says:
>
> ------------
> You should avoid EntityTransaction if you have more than one persistence
> unit in your application. Seam does not support installing multiple
> EntityTransaction beans, and the EntityTransaction interface does not
> support two phase commit, so unless you are careful you may have data
> consistency issues. If you need multiple persistence units in your
> application then we highly recommend using an EE 6 compatible server, such
> as Jboss 6.
> -------------
>
> So may be we should forbid multi-unit commits in the same request? If
> @CommitAfter is placed and there are more than one active transactions, we
> can throw an exception.
>
I think we should still add optional PUName to @CommitAfter for the case
when we have multiple active transactions,
but only want to commit one.
Also, how do you plan to start transactions? I found tapestry-jpa doesn't do
this efficiently.
(see "Make Tapestry-JPA Lazy" section here:
http://dmitrygusev.blogspot.com/2010/09/gae-and-tapestry5-data-access-layer.html
).
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: JPA: Committing transactions
Posted by Igor Drobiazko <ig...@gmail.com>.
On Wed, Feb 16, 2011 at 7:39 PM, Josh Canfield <jo...@gmail.com>wrote:
>
>
> How are you going to deal with failures when doing a multi-unit commit?
>
>
This is the big question. As EntityTransaction doesn't support 2-phase
commit, you can have a corrupt state in case of failures when doing a
multi-unit commit.
Here is for example what Seam doc says:
------------
You should avoid EntityTransaction if you have more than one persistence
unit in your application. Seam does not support installing multiple
EntityTransaction beans, and the EntityTransaction interface does not
support two phase commit, so unless you are careful you may have data
consistency issues. If you need multiple persistence units in your
application then we highly recommend using an EE 6 compatible server, such
as Jboss 6.
-------------
So may be we should forbid multi-unit commits in the same request? If
@CommitAfter is placed and there are more than one active transactions, we
can throw an exception.
Re: JPA: Committing transactions
Posted by Josh Canfield <jo...@gmail.com>.
> Well, @PersistenceUnit annotation has unitName attribute, which is used to
> idenity the unit specified in persistence.xml.
Ah. I don't use JPA.
> But the current
> questions is not how to identify the units but whether we want to commit all
> transactions at once.
Perhaps by default @CommitAfter should commit everything, and if you
want to limit it you provide appropriate @PersistenceUnit
on the onSuccess method.
How are you going to deal with failures when doing a multi-unit commit?
Josh
On Wed, Feb 16, 2011 at 10:02 AM, Igor Drobiazko
<ig...@gmail.com> wrote:
> Well, @PersistenceUnit annotation has unitName attribute, which is used to
> idenity the unit specified in persistence.xml.
>
> http://download.oracle.com/javaee/6/api/javax/persistence/PersistenceUnit.html
>
> First I would concentrate on the standard way to indentify the units; namely
> by string names. Later we can think about using annotations. But the current
> questions is not how to identify the units but whether we want to commit all
> transactions at once.
>
> On Wed, Feb 16, 2011 at 6:02 PM, Josh Canfield <jo...@gmail.com>wrote:
>
>> Can you do this with marker annotations instead?
>> @PersistenceUnit
>> @MyTestUnit
>> private EntityManager em;
>>
>> @PersistenceUnit
>> @MyOtherUnit
>> private EntityManager em2;
>>
>> @CommitAfter
>> @MyOtherUnit
>> @MyTestUnit // commit them both
>> void onSuccess() {...}
>>
>> If you recall Tom van Dijk did a lot of work getting multiple
>> hibernate sessions to work. Have you looked at his additions?
>> http://codereview.appspot.com/2896041/
>>
>> There is an email floating around with access to his git repository
>> and discussing issues of CommitAfter, etc.
>>
>> Josh
>>
>> On Wed, Feb 16, 2011 at 8:44 AM, Igor Drobiazko
>> <ig...@gmail.com> wrote:
>> > Hi all,
>> >
>> > as you probably know I'm working on the Tapestry/JPA integration. In
>> > contrast to Tynamo's integration, Tapestry's built-in JPA support will
>> allow
>> > having several persistence units in an application. This way you can
>> inject
>> > several EntityManagers into a single page, which are connected to
>> different
>> > databases.
>> >
>> > public class PersistEntity
>> > {
>> > @PersistenceUnit(unitName = "TestUnit")
>> > private EntityManager em;
>> >
>> > @PersistenceUnit(unitName = "AnotherUnit")
>> > private EntityManager em2;
>> >
>> >
>> > @CommitAfter
>> > void onSuccess() {
>> >
>> > .....
>> > }
>> > }
>> >
>> > Now I have some issues to apply Tapestry's @CommitAfter semantics to JPA
>> > resource-local transactions. With Hibernate you have a single Session, so
>> it
>> > is clear what to commit when @CommitAfter annotation is present: the
>> active
>> > transaction of the single session. With JPA you can have several
>> > EntityManagers and so several transactions. When @CommitAfter is present,
>> > you don't know which of the active transactions to commit.
>> >
>> > So, the questions is what would be the best solution? Committing all the
>> > active transactions? Maybe we could add a new attribute to @CommitAfter
>> > annotations, which expects a list of persistence unit names to commit the
>> > transactions of?
>> >
>> > @CommitAfter( { "TestUnit", "AnotherUnit" } )
>> > void onSuccess() {
>> >
>> > .....
>> > }
>> >
>> >
>> > Any thoughts or ideas`?
>> >
>> > --
>> > Best regards,
>> >
>> > Igor Drobiazko
>> > http://tapestry5.de
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
> --
> Best regards,
>
> Igor Drobiazko
> http://tapestry5.de
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: JPA: Committing transactions
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Wed, 16 Feb 2011 16:02:05 -0200, Igor Drobiazko
<ig...@gmail.com> wrote:
> First I would concentrate on the standard way to indentify the units;
> namely by string names. Later we can think about using annotations. But
> the current questions is not how to identify the units but whether we
> want to commit all transactions at once.
Agreed. How does EJB 3 deal with this? I think we should follow that.
--
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: JPA: Committing transactions
Posted by Igor Drobiazko <ig...@gmail.com>.
Well, @PersistenceUnit annotation has unitName attribute, which is used to
idenity the unit specified in persistence.xml.
http://download.oracle.com/javaee/6/api/javax/persistence/PersistenceUnit.html
First I would concentrate on the standard way to indentify the units; namely
by string names. Later we can think about using annotations. But the current
questions is not how to identify the units but whether we want to commit all
transactions at once.
On Wed, Feb 16, 2011 at 6:02 PM, Josh Canfield <jo...@gmail.com>wrote:
> Can you do this with marker annotations instead?
> @PersistenceUnit
> @MyTestUnit
> private EntityManager em;
>
> @PersistenceUnit
> @MyOtherUnit
> private EntityManager em2;
>
> @CommitAfter
> @MyOtherUnit
> @MyTestUnit // commit them both
> void onSuccess() {...}
>
> If you recall Tom van Dijk did a lot of work getting multiple
> hibernate sessions to work. Have you looked at his additions?
> http://codereview.appspot.com/2896041/
>
> There is an email floating around with access to his git repository
> and discussing issues of CommitAfter, etc.
>
> Josh
>
> On Wed, Feb 16, 2011 at 8:44 AM, Igor Drobiazko
> <ig...@gmail.com> wrote:
> > Hi all,
> >
> > as you probably know I'm working on the Tapestry/JPA integration. In
> > contrast to Tynamo's integration, Tapestry's built-in JPA support will
> allow
> > having several persistence units in an application. This way you can
> inject
> > several EntityManagers into a single page, which are connected to
> different
> > databases.
> >
> > public class PersistEntity
> > {
> > @PersistenceUnit(unitName = "TestUnit")
> > private EntityManager em;
> >
> > @PersistenceUnit(unitName = "AnotherUnit")
> > private EntityManager em2;
> >
> >
> > @CommitAfter
> > void onSuccess() {
> >
> > .....
> > }
> > }
> >
> > Now I have some issues to apply Tapestry's @CommitAfter semantics to JPA
> > resource-local transactions. With Hibernate you have a single Session, so
> it
> > is clear what to commit when @CommitAfter annotation is present: the
> active
> > transaction of the single session. With JPA you can have several
> > EntityManagers and so several transactions. When @CommitAfter is present,
> > you don't know which of the active transactions to commit.
> >
> > So, the questions is what would be the best solution? Committing all the
> > active transactions? Maybe we could add a new attribute to @CommitAfter
> > annotations, which expects a list of persistence unit names to commit the
> > transactions of?
> >
> > @CommitAfter( { "TestUnit", "AnotherUnit" } )
> > void onSuccess() {
> >
> > .....
> > }
> >
> >
> > Any thoughts or ideas`?
> >
> > --
> > Best regards,
> >
> > Igor Drobiazko
> > http://tapestry5.de
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Best regards,
Igor Drobiazko
http://tapestry5.de
Re: JPA: Committing transactions
Posted by Josh Canfield <jo...@gmail.com>.
Can you do this with marker annotations instead?
@PersistenceUnit
@MyTestUnit
private EntityManager em;
@PersistenceUnit
@MyOtherUnit
private EntityManager em2;
@CommitAfter
@MyOtherUnit
@MyTestUnit // commit them both
void onSuccess() {...}
If you recall Tom van Dijk did a lot of work getting multiple
hibernate sessions to work. Have you looked at his additions?
http://codereview.appspot.com/2896041/
There is an email floating around with access to his git repository
and discussing issues of CommitAfter, etc.
Josh
On Wed, Feb 16, 2011 at 8:44 AM, Igor Drobiazko
<ig...@gmail.com> wrote:
> Hi all,
>
> as you probably know I'm working on the Tapestry/JPA integration. In
> contrast to Tynamo's integration, Tapestry's built-in JPA support will allow
> having several persistence units in an application. This way you can inject
> several EntityManagers into a single page, which are connected to different
> databases.
>
> public class PersistEntity
> {
> @PersistenceUnit(unitName = "TestUnit")
> private EntityManager em;
>
> @PersistenceUnit(unitName = "AnotherUnit")
> private EntityManager em2;
>
>
> @CommitAfter
> void onSuccess() {
>
> .....
> }
> }
>
> Now I have some issues to apply Tapestry's @CommitAfter semantics to JPA
> resource-local transactions. With Hibernate you have a single Session, so it
> is clear what to commit when @CommitAfter annotation is present: the active
> transaction of the single session. With JPA you can have several
> EntityManagers and so several transactions. When @CommitAfter is present,
> you don't know which of the active transactions to commit.
>
> So, the questions is what would be the best solution? Committing all the
> active transactions? Maybe we could add a new attribute to @CommitAfter
> annotations, which expects a list of persistence unit names to commit the
> transactions of?
>
> @CommitAfter( { "TestUnit", "AnotherUnit" } )
> void onSuccess() {
>
> .....
> }
>
>
> Any thoughts or ideas`?
>
> --
> Best regards,
>
> Igor Drobiazko
> http://tapestry5.de
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org