1

release_lock is returning a 0 -- which according to the documentation means the lock was created by another session.

However, in the code we are creating a single session which is establishing the lock, doing multiple transactions of work, and then releasing the lock.

So somehow it seems that the DB is either losing/confusing ownership of the lock -- or that our single hibernate session is somehow using multiple different DB connections (which it wasn't/didn't do in java7).

This happens in the unit tests and after it attempts to release the lock for step X of the test and then attempts to get the lock again for step X+1 of the test at which point the application throws an error because it can't establish the lock (as it is still held by the previous execution which failed to release it).

Also - this does seem to be related somehow to the hibernate/c3p0 connection pool. Because indeed if I reduce the max pool size to 1 (meaning it only ever has a single connection to the DB) - the process works just fine.

So somehow, when the pool > 1 - it looks like hibernate is using multiple connections for a single hibernate session.

Mohit Gupta
  • 33
  • 1
  • 5
Byg Eynst
  • 33
  • 1
  • 7
  • Multiple connections for a single hibernate session doesn't sound very likely. – Kayaman Nov 15 '17 at 20:15
  • So, what do you think the problem might be @Kayaman?? – Byg Eynst Nov 15 '17 at 20:19
  • Ah you're doing multiple transactions. Well then you're very likely to have multiple connections in use (one at a time still). That's what transactions do, they define a unit of work. If you have multiple transactions, you have multiple units of work. The fix would be probably to change your design, the database works exactly as designed. – Kayaman Nov 15 '17 at 20:22
  • I can't possibly change my database design now...is there any other solutions you suggest besides changing my database design?? @Kayaman – Byg Eynst Nov 15 '17 at 20:25
  • I didn't say database design, I said design. But I don't know your code, so I can't say much. I would suggest getting rid of the `get_lock()` / `release_lock()` entirely, how to do that would depend on your code. – Kayaman Nov 15 '17 at 20:26
  • thanks for the suggestions @Kayaman, what if i don't want to get rid of get_lock() / release_lock() entirely from my code.Because it worked well with hibernate 4 ..So something has probably changed between hibernate 4 and hibernate 5 in terms of how it manages connections within a session. What other suggestions do you have @ Kayaman?? – Byg Eynst Nov 15 '17 at 21:00
  • Well you were relying on functionality that wasn't guaranteed, now it bit you in the butt. I'd be extremely wary about combining an ORM with manual locking. It's the kind of low level functionality that the ORM is trying to shield you from (for better or for worse), so it's not surprising that conflicts occur. I'd still bet this is a design issue and you're using manual locking not because you need to, but because you're used to it. Anyway, I'll tag hibernate here as well, see if someone has come across the same issue. – Kayaman Nov 16 '17 at 06:02
  • @Kayaman i used thesame design with Hibernate 4 and java 7 and it worked well,.I just upgraded to Hibernate 5.2 and Java8 and it is causing me problems. – Byg Eynst Nov 16 '17 at 16:11
  • It doesn't matter if something worked by accident. If it wasn't guaranteed to work that way, you were relying on undocumented behaviour. Something you're now paying the price for when the behaviour changed. – Kayaman Nov 16 '17 at 19:01

0 Answers0