>From: "Art S. Kagel" <art.kagel@gmail.com>
>On Jul 23, 4:07 pm, "Ian Michael Gumby" <im_gu...@hotmail.com> wrote:
> > David,
> >
> > So what you're trying to do is use the database to contain data so that
>your
> > external applications can
> > do some form of mutex locking?
> >
> >
>_________________________________________________ ________________http://liveearth.msn.com
>
>I think that the Gumby's got it. You should be using system
>semaphores or global mutex locks for this.
>
[SNIP]

Uhm thats kind of what I was afraid of...

Ok, this really isn't a database issue at all. The idea about using OS's
mutex options may not work when you're in a distributed environment. So
you'll end up having to write a mutex service.

So your mutex service would have each application register and then you can
work out the request, wait and release methods. (There's a couple of ways to
implement this...)

Having said that, you could use any relational database that supports row
level locking, stored procedures and triggers as part of an implementation.
It doesn't make sense for the applications to actually have to connect to
the database, just the service. (You can build this with two or three tables
depending on how complex you want to make this.)

I can think of a couple of use cases for this, especially if IDS was being
implemented in an embedded situation.

Incidently, if this is the case, then Oracle's bastardized user lock isn't
going to be any advantage...

But hey! What do I know?
I'm just shooting from the hip ... ;-)

-G

__________________________________________________ _______________
http://liveearth.msn.com