Hi,
It's not a technical limitation, but if I recall correctly it mirrors
the way EJB handles exceptions.
I'm actually surprised this is not configurable...
-Filip
On 2008-07-23 13:12, 9902468 wrote:
From the documentation:
The transaction will be committed when the method completes normally.
The transaction will be aborted if the method throws a RuntimeException.
The transaction will be committed if the method throws a checked exception
(one listed in the throws clause of the method).
And from the main page:
Transactions are now aborted (no longer committed) at the end of each
request: you must now explicitly commit the transaction if changes are to be
saved.
So either commit OR rollback should occur. I personally would like to use
the model where checked exceptions would cause automatic rollback also. Is
this a technical limitation or just chosen procedure? If chosen please
elaborate.
Brendan McNichols-2 wrote:
Hi all,
I have two questions/issues with tapestry-hibernate integration:
1) In my app, I am getting a "java.net.SocketException: Broken
pipe at java.net.SocketOutputStream.socketWrite0" exception (I am using
MySQL, btw) after the site has been up for a while. I have tried
several things to fix this (adding autoReconnect=true and
tcpKeepAlive=true to the jdbc url and a few other things related to
connection pooling) to no avail. Googling this exception led to a
couple of sites indicating that this problem most likely has to do with
leaving a connection open by not doing a commit on the transaction, even
after queries. I have faithfully used the @CommitAfter annotation on
all of my updates/deletes, but not on queries. Should I be using
@CommitAfter even for queries? The example at
http://tapestry.apache.org/tapestry5/tapestry-hibernate/userguide.html
seems to indicate not (because there is no @CommitAfter on the
findByName method). Would there be any other reason that a transaction
is left open without a commit? Has anyone else experienced this
problem, and if so, how did you fix it?
2) Is there a good reason why @CommitAfter does a commit even when
the method throws a checked exception? I would like my business
handling methods to rollback the transaction if the method does not
complete normally. I really want to use a checked exception so the
caller is forced to catch it.
Thanks in advance for any help!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
