Hey, thanks for the prompt replies.

Yes, I'm sure it isn't being swallowed or lost. I have a try/catch for Exception around the flush call printing the stacktrace.

Also I'd already tried debugging it. It returns OK, no errors or exceptions. The flow continues perfectly.

Show-SQL is already turned on, and that's how I know it correctly only updates in the first case (that and checking the database row), only doing a select on the second to check the version value.

Following your advice I turned on the TRACE, but couldn't find where it actually checks the version. Is it printed verbosely in the trace? All I could find was it doing an update on the version controller during the first call:

2009-09-11 11:34:03,328 DEBUG [org.hibernate.engine.Versioning] Incrementing: 3 to 4
2009-09-11 11:34:03,343 DEBUG [org.hibernate.persister.entity.AbstractEntityPersister] Existing version: 3 -> New version: 4

During the second call it just says there are no updates and the dirty checking apparently comes up empty and it just moves on without any errors.

Any other thoughts or suggestions?

Thanks,

Heliton

when you try and persist the changes to the DB is where it should throw the error.

That's where it's failing. It doesn't throw an error, exception or even return an error message. On the contrary. It returns Ok, success, all good and jiggy baby.

This way I can't warn the user his changes weren't persisted because someone else changed the item while he was editing his copy. And that's bad.

Am I missing anything here? I added the @Version and @Column tag to an Integer field in an Entity, and the field exists in the database table. I load an instance of the item row, change it, join a transaction and flush the entity manager. Is there anything else I should do or configure?

Cody Lerum wrote on Sep 11, 2009 18:19:


But your also not even seeing hibernate send the update to the database? If thats the case I don't think you have a versioning problem as it's not even getting far enough along to blow up on the update.

Thanks for the replies. That was exactly what was happening. The entity was returning false on the dirty check (on the second browser I was trying to commit the original unedited values to test if it'd overwrite the new ones from the first browser) and therefore not generating the update. Upon changing a field in the second browser the  OptimisticLockException was thrown.

Along this line (and I know this is not a Hibernate forum but since Seam was made by some of the Hibernate people someone might know), is there any way to get a notification somehow (Exception, event, return code) that it didn't actually update anything cause it wasn't dirty?

Cheers,

Heliton

Denis Forveille wrote on Sep 13, 2009 13:51:


If you not declare an exception handler in pages.xml, the OptimisticLockingException will be swallowed by seam.

Hey Denis,

That's not really accurate. I got the exception without declaring it in the pages.xml, which is the desired behavior since I want to offer the user a chance to override or merge the changed data in the database if he knows his data is more important than what the concurrent user just put up, not just print an error message page (which is the default behavior implemented by seam-gen).

I'm now having to decide on whether I'll keep the CMT and find a workaround the ended transaction to be able to load the changed data from the database, or switch to BMT and be able to only rollback if there actually was a major problem.

Thanks for the reply anyway. Wasn't aware of that endless loop problem. Glad I still haven't upgraded to 2.2 yet. Guess I'll just wait for Seam 3.0 with JSF2.

Cheers,

Heliton

You were saying in you first post that ... only doing one update for the first occurence, and incrementing the version field value, but it returns successfully, without throwing the OptimisticLockException. .

Read the other posts. I eventually solved it with help from the nice folk here.

So now you now receive an exception?

Are you in a long running conversation?

Yes to both.

How do you catch the OptimisticLockingException to display a valid message to the end user and give him a chance to respond ? with an interceptor?

No. My submit button calls a business method that has a try/catch around it. I set the flush mode to manual and when I call entityManager.flush(), there it is! :)
Then in the catch clause I queue a message in statusMessages and do some other business related processing, like preparing the context for the user to be able to decide whether to keep or discard his work.

Does your exception occurs during the automatic EJB/CMT commit ?  Or do you force a em.flush() before the end of the method and catch the exception ?

No, not using automatic. Was having way too much trouble with it, and I need/like having control over the transaction boundaries, specially since we like to have as much error handling as possible so the user is less troubled by common problems that can be solved in the background. That's why we're (supposedly) paid the big bucks ;)