RE: Named user lock facility in IDS?




From: "David N. Heydon" <david.heydon@xxxxxxxxxxxxxxxxxx>
>the idea about using OS's mutex options may not work when you're in a
distributed environment

That is indeed a potential issue and a reason to try to maintain locks
within the database. Looks like I'll have to have another look at coding a
locking service at some point...

Thanks again to those who responded.

David


David,

Why do I get the feeling that this is more of a graduate level course problem than a real world business problem?

Is this a stand alone project, or one that is part of a larger database centric initiative?

If its stand alone, then a database would be overkill unless you've got an extreme situation where you're going to have a lot of lock requests.

I can only think of a couple of handfull of situations where this may be an issue.

The reason I think this is more of a student's problem is that it appears to be an extension to the simple mutex problem. (Dining philosophers, librarian checkout, etc ...)

The trick is that you're probably looking to "lock" multiple resources at a time, so you have to worry about deadlocks, along with the fact that you're not really locking the resource at all, so somebody who's not using the locking system can still access the resource and potentially gum up the works.

You can do this using the following languages:

Java,
Ruby,
Python,
C/C++/ESQLC

You can still use the database, its a novel approach, however the overhead is going to be a bit expensive.

Note to Art... The mutex locking mechanisms aren't OS specific. Sure OSs have to do mutex locking, and there are prebuilt libraries that have the lower level stuff already written for you, but that doesn't mean you can't write your own. ;-)

This would be an interesting problem, but I'd hate to be the one trying to write some deadlock handling code in SPL. ;-)

So if you *are* going to using a database, you would be better off using IDS or Cloudscape.

But hey! What do I know.
Its too friggin early in the morning and I need my first cup of coffee. ;-)

-G

_________________________________________________________________
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_2G_0507

.

Relevant Pages

  • Re: [PATCH] drivers/isdn/gigaset: new M101 driver
    ... It is doubtful if the locking here does anything useful. ... It assures atomicity when reading the cs->cmdbuf pointer. ... This doesn't look like a case for a mutex to me, ... reason reducing the number of callers would help that. ...
    (Linux-Kernel)
  • Re: PTHREAD_MUTEX_INITIALIZER
    ... reason internal to the implementation, so you need to check the return ... anything sane if locking a mutex fails for no application-level ... Locking that mutex might not fail, ...
    (comp.programming.threads)
  • Re: Multiuser Problem
    ... Pessimistic locking - in todays modern languages this is not really the ... requires that you have a database transaction locking the row of the record ... Allow the user to edit the row but before you write the data back to ...
    (microsoft.public.dotnet.languages.vb)
  • RE: 2nd form with recordset of 1st
    ... processes using this table using optimistic locking? ... If this is a split database, is there a persistent connection to the back ... Every directory traversed requires Windows to ... > record source to be the 1st forms recordset? ...
    (microsoft.public.access.formscoding)
  • Re: Ping Marco Bambini
    ... Sounds like deadlock to me, ... I believe Marco recommended the mutex to keep code from doing exactly ... until the original thread exited the mutex? ... often make rapid updates to the database in a loop. ...
    (comp.lang.basic.realbasic)