db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hawley, Dan" <dan.haw...@lmco.com>
Subject RE: Issues with Record Locking
Date Thu, 03 Sep 2009 14:51:03 GMT
Hi Sylvain,

Thanks for your excellent response to my request for help.  I too am worried that I am confusing
Hibernate and Derby locks.  My goal is use derby locking because we will have multiple desktop
applications accessing the derby network database so it seems to me the best place to lock
records is at the source.

I definitely think I need to look at the sql statements that are being generated by hibernate
and see if they look correct for what I am trying to accomplish.  My major concern was that
I was asking Derby to do something that it couldn't handle.  It sounds like, from your response,
that what I am trying to accomplish is possible.

Thanks again for the advice!!!  Dan

-----Original Message-----
From: Sylvain Leroux [mailto:sl20@wanadoo.fr]
Sent: Thursday, September 03, 2009 1:15 AM
To: Derby Discussion
Subject: Re: Issues with Record Locking

Hawley, Dan a écrit :
> Hi,
> I seem to need some help understanding how record locking works in
> Derby because I can't seem to make it work for me.
> Any help you can provide will be greatly appreciated.  Thanks, Dan

Hi Dan,

Well, if "any" help will be appreciated, I take my chance!
That's quite a long time I haven't used Hibernate. So I'm a little bit
rusty. But, I am wondering if you don't mix up two things:
* Database locks
* Hibernate locks

As far as I know, database locks allow one to prevent other transactions
to access some rows from a table while you are holding it.
With Derby, you may achieve such exclusive access by using
a LOCK TABLE statement (among others). This is not recommended if you
intent to hold the lock for a long period of time.

Depending on your needs, you may be interested in more informations
about Derby's Locks:

In the other hand, as far as I remember, Hibernates locks are something
else: they will prenvent the modification of the same persistent objet
in two different contexts.
By default, Hibernate use optimistic locking. Only when a dirty object
(i.e.: an object you have modified) is write back to the DB, Hibernate
is able to say: "Hey, I can't do that: Someone has changed it in your

Concerning your specific problem, in theory,
'setHint("org.hibernate.readOnly", true)' will prevent Hibernate to
"persist back" the object to the DB. I don't think this will change the
SQL query in any way. Moreover, in your case, I guess your second query
will hit the cache, returning the same "updatable" objects than the
first one. Once again, this is only a guess. And I couldn't say if this
a bug or a feature.

At least, I think this is more of an Hibernate than a Derby issue.

Finally, maybe I totally missed the point here ;) So if you think this
is definitively a Derby problem, please log the SQL query issued by
Hibernate: this will give us a better understanding of what's going on

Anyway, let us know if you solved your problem.

Hope this helps at least a little,

Website: http://www.chicoree.fr

View raw message