Lenny it is easy. Look at the issue there I used a 5.1 code and changed
four lines. Done it this way and there are no additional commits just like
the actual documentation suggest it. The rest can be made optional. I did
it here locally.
The problem with hibernate bugged me. Never was aware of such a different
behaviour I always expected the persistent context to be cleared after
commit. And like I said I just need someone in the Jira who cares. Not more.
>What you ultimately should do is put in an advisor to disable @CommutAfter
completely,
and move all transactional code outside the presentation layer (Tapestry)
and move it into
JEE business logic layer, which will support all of your transactional
needs.<
Sadly the current implementation of the project has its business logic
layer inside tapestry. Thats why my coworkers used @CommitAfter annotations
in the first place. So there is nothing like a rest-like api and a
dedicated server process for the internode communication. All just plain
Tapestry <--Hibernate--> Database stuff. And this should work out of the
box. Like I said I dropped Tapestry for this reason back in 2008 after one
year of joy and used it only to do some basic stuff for a GWT frontend. But
this was inhouse. Now this is a public site. So no such fun.
Fix it, please. The additional commits wont happen while changing three
lines of code in the 5.1 version ok now its stripped down.
Cheers,
Martin (Kersten)
PS: Dude I never bagged that much for a critical bug being fixed. wt_?
2013/9/7 Lenny Primak <lpri...@hope.nyc.ny.us>
> This is not as easy as yo are saying ,to solve this, in a compatible way,
> that works for everybody.
> I think once you really start thinking about it in a generic way, you open
> up such a can of worms
> that your head will spin. What I suggest you do is follow the multiple
> suggestions given to you already.
>
> Now, I know its frustrating, its not what you want in your case, etc.
>
> My take on this is what you really want os JEE behavior.
> What you ultimately should do is put in an advisor to disable @CommutAfter
> completely,
> and move all transactional code outside the presentation layer (Tapestry)
> and move it into
> JEE business logic layer, which will support all of your transactional
> needs.
>
> This is not as difficult as you think, and you won't have to worry about
> errors in
> the _very_ basic implementation, which @CommitAfter is.
>
>
> On Sep 7, 2013, at 7:50 AM, Martin Kersten wrote:
>
> > Hi Howard,
> >
> > I dont rant about the checked exception stuff. That is how it is ment
> > to be and I like this. I rant about this nested commit behaviour and see
> my
> > coworker using session.save on not annotated service methods which only
> > work because he calling another service method doing the commit for his
> > method and alike. He also managed to make changes that are rolled back
> (no
> > commit after) and since it was for the statistics noone noticed up to now
> > when I did this strict check.
> >
> > Thats what I ment is broken.
> >
> > so like: withoutCommit() {session.save}; withCommit() {doSomething} ->
> works
> > so like: withCommit() {do something, withAnotherCommit()
> {doSomethingElse}
> > doSomethingMore} -> two commits, broken transaction and so on
> >
> > My coworker managed to get this totally wrong. So I guess he is not the
> > only one. I downvoted (2008) using Tapestry on my former employee because
> > of this unfixed transactional behavior and now I notice this basic flaw
> is
> > still in there. I understand using it only to annotated pages is working
> > but sadly the comment of CommitAfter says it can be used for service
> > methods and thats where the fun part starts and even more sadly Hibernate
> > has its own flaws since if you are using Hibernate transaction to commit
> it
> > does not do a persistence context clean up.
> >
> > This is only done in JPA / EJB3 mode or using JTA. So it works more like
> a
> > transaction commit never happend (only the locks are released and some
> > actions are processed). I was really sorry for hibernate doing it this
> way.
> > I even remembered witnessing a talk about it in '03 I guess. I dont
> > remember the argument why this was initially used. It was something to
> > speed something up or allow proxy lazy loading or somekind of this.
> Proxys
> > for example are automatically reattached so mixing up two sessions
> produces
> > weired experiences but work since usually you work against a single
> > database and you dont care for 'Phantom reads' and stuff like this. I
> never
> > thought thinks are so mixed up, too. Nightmare if you work test first and
> > you can not test those things.
> >
> > And since the current projects are all using this and changing the
> > Hibernate module to work in compliance with JPA which would fix this
> issue,
> > it will break. I understand most of the pros use Spring Transactions and
> > stuff, but there are lots of people dont using it.
> >
> >> But if you are unhappy, you can *easily* roll your own annotation and
> > worker; the code is ridiculously simple.<
> >
> > Yeah thats why I cant believe this was not fixed yet. This is a major
> flaw.
> > Its broken and there must be done at least to fix the nested AfterCommit
> > produces additional commits. Which is the main reason I have a rant about
> > this one.
> >
> > Also introducing two simple Transactions and do some argumenting on the
> > Session object would easily solve this issue for most of the user of
> > @CommitAfter. So one can state that using those is better then this. Or
> > maybe one can switch the session to apply to JPA and do a persistent
> > context clean up after each transaction commit would help and people
> > ranning into the issue that the code breaks when moving to lets say 5.4
> get
> > an explaination how they can switch off the JPA appliance so the code
> > worked like before but database transactions are being broken.
> >
> > So all I need is an active maintainer that discuss the steps on the issue
> > https://issues.apache.org/jira/browse/TAP5-2159 and coordinate the
> code. So
> > I dont need to add this code to my projects and tell clients about this
> > flaw when they ask what this is. It is ridiculous to have something that
> > broken in a framework like tapestry.
> >
> > Cheers,
> >
> > Martin (Kersten)
> >
> >
> >
> > 2013/9/7 Howard Lewis Ship <hls...@gmail.com>
> >
> >> The checked exception behavior was explicit and on-purpose; it is
> in-line
> >> with what the EJB containers do: a checked exception represents a
> failure
> >> from which some recovery is possible, as opposed to a runtime exception
> >> which leaves the system in an unknown state (therefore, rolling back the
> >> transaction makes sense).
> >>
> >> But if you are unhappy, you can *easily* roll your own annotation and
> >> worker; the code is ridiculously simple.
> >>
> >>
> >>
> >> On Fri, Sep 6, 2013 at 1:21 PM, Martin Kersten
> >> <martin.kersten...@gmail.com>wrote:
> >>
> >>> Hi there,
> >>>
> >>> here is the CommitAfter freak again. I need this to be fixed asap. I
> >>> have all the code ready but the JIRA issue
> >>> https://issues.apache.org/jira/browse/TAP5-2159 is not moving.
> >>>
> >>> I am very unpleased with the situation. Since its the same problem I
> had
> >>> 2008 and it was not fixed and I did a rant back there too.
> >>>
> >>> Lets recap the description of the @CommitAfter annotation:
> >>>
> >>>>> Marks a method of a service (or a component method) as transactional:
> >>> the active transaction should
> >>> commit<
> >>>
> >>
> http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/hibernate/HibernateSessionManager.html#commit%28%29
> >>>> after
> >>> invoking the method. Runtime exceptions will abort the transaction,
> >>> checked exceptions will *also commit* the transaction. <<
> >>>
> >>> So please let us fix this once and for all.
> >>>
> >>> I also have some code to protect others from doing some of the
> dangerous
> >>> stuff like using a session to store information in a read only mode
> >>> (FLUSH_NEVER, connection=readonly) and also I have @ReadOnlyTransaction
> >> and
> >>> @WriteTransaction to be used instead of @CommitAfter to be more strict.
> >> It
> >>> should not break the behavior of @CommitAfter (after it is fixed to the
> >>> behavior it was intended to do).
> >>>
> >>> So please, give me a call and I will commit this and this issue is gone
> >>> once and for all. I cant stand Tapestry to be flawed this way.
> >>>
> >>>
> >>> Just give me a call and we get this done in a evening. I will do most
> of
> >>> the work so go ahead. This is free as in free.
> >>>
> >>>
> >>> Cheers,
> >>>
> >>> Martin (Kersten)
> >>>
> >>
> >>
> >>
> >> --
> >> Howard M. Lewis Ship
> >>
> >> Creator of Apache Tapestry
> >>
> >> The source for Tapestry training, mentoring and support. Contact me to
> >> learn how I can get you up and productive in Tapestry fast!
> >>
> >> (971) 678-5210
> >> http://howardlewisship.com
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
