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 <[email protected]>
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
<[email protected]> 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
<[email protected]>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
<[email protected]> 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: [email protected]
For additional commands, e-mail: [email protected]
--
Best regards,
Igor Drobiazko
http://tapestry5.de
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
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: [email protected]
For additional commands, e-mail: [email protected]
