evans@decvax.DEC.COM (Marc Evans) (03/15/91)
I am using the dbm (ndbm too) facilities provided by perl. It would appear
that the file(s) opened by dbmopen are not locked and therefore data can be
lost if more then one process attempts to modify the database at the same
time. It would also appear that this may be caused by the library functions
on the host, not perl itself.
Has anybody else had this type of problem, and if so, how did you go about
performing locking?
Thanks in advance - Marc
--
===========================================================================
Marc Evans - WB1GRH - evans@decvax.DEC.COM | Synergytics (603)635-8876
Unix and X Software Consultant | 21 Hinds Ln, Pelham, NH 03076
===========================================================================tchrist@convex.COM (Tom Christiansen) (03/15/91)
From the keyboard of evans@decvax.DEC.COM: :I am using the dbm (ndbm too) facilities provided by perl. It would appear :that the file(s) opened by dbmopen are not locked and therefore data can be :lost if more then one process attempts to modify the database at the same :time. It would also appear that this may be caused by the library functions :on the host, not perl itself. This is certainly true. dbm doesn't do locking. To do record locking would be hard. You could easily enough protect it with file locking though, but you should do this in your own code. --tom
rbj@uunet.UU.NET (Root Boy Jim) (03/15/91)
In article <1991Mar14.205242.23220@convex.com> tchrist@convex.COM (Tom Christiansen) writes:
?From the keyboard of evans@decvax.DEC.COM:
?This is certainly true. dbm doesn't do locking. To do record locking
?would be hard. You could easily enough protect it with file
?locking though, but you should do this in your own code.
Record locking might well be impossible, dunno.
File locking is easy, unless, of course you are using NFS.
Another thing to do is run a database demon and ask it to do things for you.
--
[rbj@uunet 1] stty sane
unknown mode: sanetchrist@convex.COM (Tom Christiansen) (03/15/91)
From the keyboard of rbj@uunet.UU.NET (Root Boy Jim): :File locking is easy, unless, of course you are using NFS. Use lockf (fcntl) instead of flock then. And risk hanging forever should the lockdaemon go south. Actually, I haven't had too much trouble with it in the last few months on this particular machine, but on other convexen here there have been occasional anomalies. --tom
rbj@uunet.UU.NET (Root Boy Jim) (03/15/91)
In article <1991Mar14.235335.1712@convex.com> tchrist@convex.COM (Tom Christiansen) writes:
?From the keyboard of rbj@uunet.UU.NET (Root Boy Jim):
?:File locking is easy, unless, of course you are using NFS.
?
?Use lockf (fcntl) instead of flock then. And risk hanging forever
?should the lockdaemon go south. Actually, I haven't had too much
?trouble with it in the last few months on this particular machine,
?but on other convexen here there have been occasional anomalies.
WHAT lock daemon? It seems that vendors which are stupid enuf
to implement dual universes can't be bothered to update their NFS.
BTW, what does NFS do with O_CREAT|O_EXCL?
Don't tell me, I think I know...
--
[rbj@uunet 1] stty sane
unknown mode: saneevans@decvax.DEC.COM (Marc Evans) (03/15/91)
In article <125585@uunet.UU.NET>, rbj@uunet.UU.NET (Root Boy Jim) writes: |> In article <1991Mar14.205242.23220@convex.com> tchrist@convex.COM (Tom Christiansen) writes: |> ?From the keyboard of evans@decvax.DEC.COM: |> ?This is certainly true. dbm doesn't do locking. To do record locking |> ?would be hard. You could easily enough protect it with file |> ?locking though, but you should do this in your own code. |> |> Record locking might well be impossible, dunno. |> |> File locking is easy, unless, of course you are using NFS. |> |> Another thing to do is run a database demon and ask it to do things for you. Let's assume for the moment that I'm not using NFS (even though I am in reality, and to make things even worse, locking is done because many machines want write access to this dbm database). In perl, dbmopen doesn't use a FILEHANDLE, and flock requires a FILEHANDLE. We therefore end up with something like the following: $dbname = "foo"; open(LOCKDB,"$dbname.pag"); flock(LOCKDB,2); dbmopen(%foo,$dbname,0666); [...] dbmclose(%foo); flock(LOCKDB,8); It really seems ugly to me that the script needs to understand dbm naming conventions to perform the locking. Also, think about the exception handling that really should be added to the above for the cases of open, flock and dbm* functions failing. Not very pretty. However, it would appear that short of creating a network dbm data server, this technique is probably my best option. Any other suggestions? - Marc -- =========================================================================== Marc Evans - WB1GRH - evans@decvax.DEC.COM | Synergytics (603)635-8876 Unix and X Software Consultant | 21 Hinds Ln, Pelham, NH 03076 ===========================================================================
mmuegel@fwhnm02.fwrdc.rtsg.mot.com (Michael S. Muegel) (03/16/91)
In article <21131@shlump.nac.dec.com> evans@decvax.DEC.COM writes: >It really seems ugly to me that the script needs to understand dbm naming >conventions to perform the locking. Also, think about the exception handling >that really should be added to the above for the cases of open, flock and dbm* >functions failing. Not very pretty. > >However, it would appear that short of creating a network dbm data server, this >technique is probably my best option. Any other suggestions? This is probably your basic script-minded, simplistic approach but I just have routines that create .lock files for the dbm files. I only trust this for a few scripts I have written that all work on the same dbm databases, but it seems an easy way aroud file locking problems. Especially since file locking is hell in Domain/OS to begin with :-(. Since nobody in their right mind would want to update these dbm files outside of my Perl scripts it works peachy. And yes, I handle interrupts and stuff in a signal handler to remove the .lock file if all hell breaks loose :-). -Mike
les@chinet.chi.il.us (Leslie Mikesell) (03/16/91)
In article <21131@shlump.nac.dec.com> evans@decvax.DEC.COM writes: >Let's assume for the moment that I'm not using NFS (even though I am in reality, >and to make things even worse, locking is done because many machines want write >access to this dbm database). Gdbm seems to include some locking code - does anyone know if it is reliable? (Maybe this application would be a good test...) Les Mikesell les@chinet.chi.il.us
oz@yunexus.yorku.ca (Ozan Yigit) (03/18/91)
In article <21131@shlump.nac.dec.com> evans@decvax.DEC.COM writes: >It really seems ugly to me that the script needs to understand dbm naming >conventions to perform the locking. At least one ndbm-clone, namely sdbm provides an alternative for those "naming conventions", it comes with an interface where the user can specify the names of the data and index files. Better still, use berkeley "hash" package. [Btw isn't it about time perl include support for b+tree databases?] oz --- Not all good things come with three | internet: oz@nexus.yorku.ca pages of dogma and an attitude. - anon | uucp: utzoo/utai!yunexus!oz