On Wed, Mar 01, 2006 at 04:00:53PM -0600, Jim C. Nasby wrote:
> On Wed, Mar 01, 2006 at 01:53:45PM -0800, w b wrote:
> > Well, my locking data isn't as simple as "locked, not
> > locked". The resource has ranges that can be locked, and it
> > can be locked for reading (shared) and writing (exclusive).
> > It's not really fun.
>
> Sounds to me like the best bet is to put the 'resources' into a database
> and let it handle the locking...
Letting the db handle it, isn't really an option: For
starters, I can't put any possible range of the resource
into the db.
I intended to only put the locks as such in the db.
When it comes to a new lock, I'll select all relevant old
locks, that might conflict, handle the conflict check in
app logic and finally insert a new lock record. (all inside
a proper table lock/transaction).
I just hoped for some cool way to let the db cleanup all
those records, when the session dies.
(not, that I have that now ;) )
Elrond
