The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

dabooka (3) [Avatar] Offline
Hi Folks,
just trying out some more examples from the book. In chapter 4, page 128, it states that "Changes made before the call to lock() aren't propogated to the database".

So, I thought I'd try it out.

I set up an example pretty much identical to that on the page. Using a username and a firstname in a mysql database.

Surprisingly, Hibernate also propogated the change I made to the user object between transactions, and prior to the lock(). I also moved the change into the second transaction, but again prior to the lock. The change was propogated.

Is this an error in the book or - again, more likely - am I missing something?

Any advice would be great.

See code below. I set the database values to something other than firstname of "Mathew" and username "wonka". However, on inspection after run, both the firstname "Mathew" and username "wonka" changes were made, despite the firstname change being made prior to the lock.

I'm going to try again but without the username change.

Session session = HibernateUtil.getSessionFactory().openSession();
User user = (User) session.get(User.class, 4L);


Session sessionTwo = HibernateUtil.getSessionFactory().openSession();
Transaction tx2 = sessionTwo.beginTransaction();

sessionTwo.lock(user, LockMode.NONE);


dabooka (3) [Avatar] Offline
Re: Error in chapter 4 p128 on calls to lock?
Hi again,
ok I removed the username change and sure enough, no changes at all were propogated.

I also tried moving the firstname change into the second transaction, but prior to the lock. Again, no change.

I removed the lock statement. Again, no change. I suppose now that the object is still detached.

I put the lock statement back in, and move the firstname change after the lock statement. This time, the changes are propogated.

OK, I think I've figured this out. Lock associates the object with the session, but it doesn't "freeze" any changes that have been made to the object beforehand. Any changes that are made after the lock, in addition to any before, are then committed at the end of the transaction/session.

Sorry to be a pain! I hope this helps someone.