Sorry if I did not explain the problem fully enough.

I have an Informix database which does not have transactions.
I'm looking for some locking primitive functions which I could use to
control access to common resources, i.e.

Process A.. Process B..

Wait_for_lock("ABC") SubprocessX()
SubProcessY() Wait_for_lock("ABC")
release_lock("ABC") SubProcessY()
Release_lock("ABC")

A given process should be able to have multiple "locks" active at any time.
Ideally "locks" are basically just a named resource, (i.e. a string), so
they are very flexible, and could relate to anything, even stuff outside the
database, i.e. a printer. If possible I'd like the ability to:-

1. Wait for a given lock for X (0+) secs, returning an error code if lock
cannot be acquired after X secs.
2. Check if a given lock is active without acquiring a lock
3. Unlock a given lock.

I would like the above to work without transactions. If transactions were
active then I would like locks to exist until explicitly unlocked/released
(i.e. across transactions). DBMS_LOCK() provides this facility. I could do
the same with LOCK TABLE in a db without transactions, but having to have a
dummy table per lock is messy at best...

I hope this makes it clearer.

TIA,

David

-----Original Message-----
From: Art S. Kagel [mailto:art.kagel@gmail.com]
Sent: 20 July 2007 19:51
To: informix-list@iiug.org
Subject: Re: Named user lock facility in IDS?


On Jul 20, 5:59 am, "David N. Heydon"
<david.hey...@LangdonSystems.com> wrote:
> Thanks for the suggestion Madison. I have a problem in that the database
> does not use transactions... Also, even if it did would this work as I
> thought the COMMIT would release all locks in the transaction, so if
process
> A locked rows B and C and then unlocked row B then row C would also be
> unlocked too... Am I missing something obvious here?
>
> TIA.
>
> David
>
> -----Original Message-----
> From: Madison Pruet [mailto:mpru...@verizon.net]
> Sent: 19 July 2007 13:08
> To: informix-l...@iiug.org
> Subject: Re: Named user lock facility in IDS?
>
> David N. Heydon wrote:
> > I wonder if someone could comment on if Informix IDS has a named user
> > locking facility. I'm looking for the ability to lock things on the
> database
> > server without being restricted by tables/rows/transactions etc. I
would
> > like to use this for all sorts of things within applications where
> > controlled access is required to a given resource, i.e. access to a file
> on
> > a filesystem,,
>
> > I was looking at Oracle recently and noticed it includes a facility like
> > this in a package called DBMS_LOCK. See
>
> http://download-uk.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_l...>
for further info.
>
> > Any thoughts on how to achieve something similar with Informix IDS would
> be
> > most welcome!
>
> > Cheers,
>
> > David
>
> Create a table call is something like "lock_table". Make it "lock mode
> row".
>
> create table lock_table {
> lock_name varchar(255) primary key,
> hold_lock integer
> } lock mode row;
>
> To 'allocate a lock', simply insert a row into the lock_table.
>
> To set the lock "update lock_table set hold_lock = hold_lock + 1 where
> lock_name = "my lock";
>
> To release the lock - commit.

Madison's point is:

if you want to make certain that only one user at a time can perform
an operation (it sounds like that's what you want), then with a
lock_table in existence, all user's would be required to insert or
update a row in the lock_table with a particular lock_name value.
That user would do so within a transaction, holding the lock by NOT
committing or rolling back the transaction until he had completed all
related work. Once the work is completed the COMMIT will release the
lock allowing another user in to acquire the lock.

If that's not what you intended, then be more specific. Pointing us
at the Oracle manuals is NOT a good way to help us understand what
this DBMS_LOCK function is supposed to accomplish, or even if that
would be the best solution to your problem if you were using Oracle.
Most of us avoid reading Oracle manuals for fear of contracting some
dread incurable disease.

The following is intended for all posters to this NG, not just
David:

PLEASE PLEASE DO NOT POST your unworkable possible solution and ask us
how to make it work. It is FAR BETTER to post the actual problem and
ask us how we would or in fact DO solve it ourselves.

If you can find it, or Jonathan posts it again, see the paper on
Newgroup Etiquette someone once wrote.

Art S. Kagel

_______________________________________________
Informix-list mailing list
Informix-list@iiug.org
http://www.iiug.org/mailman/listinfo/informix-list