Em Sat, 30 May 2009 18:17:46 -0300, Juan E. Maya
escreveu:
I was thinking about something similar to what spring has to offer.
Me too. :) But using EJB3 annotations (are they part of a standard), not
the Spring ones, of course. I guess the step after this one would be to
build some secu
I was thinking about something similar to what spring has to offer. So yes,
i think it should be in Tapestry IoC. Personally, one of the only things i
miss from Spring is its transactional support.
On Sat, May 30, 2009 at 10:07 PM, Thiago H. de Paula Figueiredo <
thiag...@gmail.com> wrote:
> Em
Em Sat, 30 May 2009 11:02:52 -0300, Juan E. Maya
escreveu:
This sounds awesome Thiago. I could give u a hand if you want.
Nice to know I'm not the only one wanting transaction support in Tapestry.
:)
However, i still think that such library should be part of the core
framework.
Tapes
This sounds awesome Thiago. I could give u a hand if you want.
However, i still think that such library should be part of the core
framework.
On Fri, May 29, 2009 at 2:27 PM, Thiago H. de Paula Figueiredo <
thiag...@gmail.com> wrote:
> On Fri, May 29, 2009 at 6:12 AM, Juan E. Maya wrote:
> > hmm
On Fri, May 29, 2009 at 6:12 AM, Juan E. Maya wrote:
> hmm so @CommitAfter works as REQUIRES_NEW. A new transaction is created for
> each method.
> It would be great if the core support for hibernate would add more
> transactional support. Maybe for 5.2? :) Does anybody know if there are
> plans f
hmm so @CommitAfter works as REQUIRES_NEW. A new transaction is created for
each method.
It would be great if the core support for hibernate would add more
transactional support. Maybe for 5.2? :) Does anybody know if there are
plans for something like this?
On Thu, May 28, 2009 at 8:04 PM, Rober
Not quite.
The commit happens immediately after function exit, and it commit the
current transaction, subsequent actions will then be performed in a
new transaction, as detailed by Igor.
So, the flow for your scenario is (assuming you haven't committed the
current transaction (t1) before cal
Thanks Igor,
I think i understand it now. Basically every function which is annotated
with @CommitAfter will be commited at the end of the request when session is
detached. I guess the only way is to group together whatever i wanted to
achieve into a single function and have it @CommitAfter.
Ig
@CommitAfter commits the transaction of the request. The transaction is
created when the session is attached to the request. When functionB() is
called the transaction will be committed and a new one will be created. So
functionA() will commit the later transaction.
On Tue, May 26, 2009 at 5:46 AM
A quick question about tapestry-hibernate rollback propagation. As far as i
know, any function annotated with @CommitAfter will create a new transaction
similar to EJB required_new. But how would the nested functions behave?
For eg.
@CommitAfter
public void functionA() {
functionB();
}
@CommitA
10 matches
Mail list logo
