RE: Named user lock facility in IDS?

>From: "David N. Heydon" <david.heydon@LangdonSystems.com> > >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

On Jul 24, 6:04 am, "Ian Michael Gumby" <im_gu...@hotmail.com> wrote: <SNIP> > 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. ;-) <SNIP> I knew that ;-) I mentioned 'OS Semaphores' as opposed to global mutexes. The semantics are different, and yes there are lots of libraries that implement locking. Unfortunately you have to be careful, many are targeted at local mutex handling to control resources within a single multi-threaded task. To lock between separate tasks you need global level mutexes or semaphores (and yes I also know that on UNIX at least global mutexes are implemented using semaphores). Almost all semaphore implementations today adhere to POSIX syntax and semantics, I didn't mean to imply that sempahores were OS dependent. What I clearly missed what that the dude might be trying to implement a distributed locking mechanism. Something Oracles particularly expert <gag gag gag> at. ;-) Art S. Kagel Art S. Kagel

>From: "Art S. Kagel" <art.kagel@gmail.com> ><SNIP> > >I knew that ;-) > >What I clearly missed what that the dude might be trying to implement >a distributed locking mechanism. Something Oracles particularly >expert <gag gag gag> at. ;-) > I guess I missed your sarcasm. ;-) (Oracle's locking is of no use, here....) Uhm, yeah Posix Compliant semaphores would be a good start. The idea that the OP had with using a database would work if you wanted to implement the semaphores using database tables for a backing store. (Storing the lock requests, and the locks in two different tables.) Here you're not actually locking the resource, but trusting that your BPs all comply and use the centralized locking service. To take it a step further, you could then put a lock manager (would have to run as root) on each of your linux/unix servers that you wanted to secure resources. Then you'd be able to actually lock the files. The only catch is that there's a small window of time where the lock manager releases a file and the application takes control that a different non-compliant process could take control of the file resource. (Small window, but it could be exploited.) Its an interesting problem ... _________________________________________________________________ http://liveearth.msn.com