Hi Alex,
no, unfortunately I'm not in San Francisco at the moment :(
Your comments though led me to check my configuration and I realised that I had
set up transactions in Spring even for pure reads which I think we used on our
last project and I never looked at it again. Copy & paste got me again.
So now I set up transactionless reads. This means I can simply insert all the
incoming HTTP params into my model, and if struts validation fails, it all drops
out of the EntityManager once my OpenSessionInView closes it up.
Much more logical and intuitive I think, after all - apart from that update()
situation.
Alexander Snaps on 08/05/08 22:02, wrote:
Still didn't take the time to look into the code :(
By any chance, are you at JavaOne? We might try to check it out together,
what do you think?
Alex
On Fri, May 2, 2008 at 4:01 AM, Adam Hardy <[EMAIL PROTECTED]>
wrote:
My curiosity finally got the better of me and I put the JPA transaction
issue to test, and I have to concur with you.
What threw me off the scent is the update method I have on my business
managers, on which the transactional boundary is set in Spring.
The update() method doesn't sit well with JPA. As you rightly said, all
that is needed to trigger an update is a transaction.
In effect, the update() method on my business manager doesn't have to
contain any code at all - just the fact that it invokes the transaction will
be enough to ensure that all the entities in the entity manager are flushed.
And that's not good for intuitiveness - if someone new read the code and
saw that I had edited 2 entities but only called update() on one, they would
obviously ask why on earth the second entity magically updated. I guess I'll
have to work out a refactoring.
Alexander Snaps on 02/05/08 10:18, wrote:
It'll probably be around the tx...I've been doing this within Swing apps,
trying to fix the wizard in Netbeans around JSR 295, 296 and JPA. Come see
my
presentation at JavaOne on the subject ;) But I need to see if this can be
applied to this situation. I still don't get how changes done while
applying
the values actually are within a tx demarcation... Doesn't translate in
some
weird tx management issue? Why would you have the tx begin during these
phases?
On Fri, May 2, 2008 at 11:11 AM, Adam Hardy <
[EMAIL PROTECTED]> wrote:
Alexander Snaps on 02/05/08 10:04, wrote:
On Thu, May 1, 2008 at 5:49 PM, Eric D. Nielsen <[EMAIL PROTECTED]>
wrote:
Alexander Snaps <alex.snaps <at> gmail.com> writes:
I know I am repeating myself, but what is getting in the way of NOT
starting
a transaction at all in the case of a validation error... Shoudn't the
transaction be started much later anyways, and only if validation
passed?
Because that doesn't solve the problem. No transaction has been
started explicitly. The underlying problem is that there are two
sources of implicit transactions that can be triggered.
1) Explict session/entityManager.flush() in the cleanup code of
OSIV/OEMIV filters
2) Implicit flush before queries. FlushMode settings appear to help in
some cases, but I've seen reports where it appears that the setting
isn't always respected.
If a transaction hasn't been started, either of these cases (ie falling
out the bottom of OSIV/OEMIV, or a lazy load query) can trigger
writing data to the DB.
no, w/o tx nothing ever gets flushed to the db... I explained the
behavior you'd get in a previous message. I'll check out the code on my
flight to SF (should I remember to check it out of scm ;) ) I'll try to
get back to you with something more concrete...
I for one will be interested to see what you come up with!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
