RE: Named user lock facility in IDS?

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

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. Also any database without logging (ie without transactions) is HIGHLY at risk for catastrophic data loss! If you can turn logging/ transactions on for those databases at once! If your apps are not properly written to handle locking then recode the immediately and turn logging on ASAP. You may also be able to take advantage of IDS 11 (Cheetah)'s new isolation level (COMMITTED READ ... LAST COMMITTED) to avoid concurrency and lockout issues while maintaining data integrity and safety with minimal recoding. Art S. Kagel

>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