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
>
