Gregg Irwin wrote: > Hi Alan, > > A> I'm making a small "Phonebook" type data base program that I want to access > A> from several computers on a local net and maybe remotely. I was originally > A> going to use a text file to store the data but I'm thinking that there is a > A> possibility that it might be accessed by two different people at the same > A> time. Without going with a MySQL database what methods can I use to insure > A> that simultaneous access will not screw up the data base file. > > There is no definitive solution for this, aside from using a real > database; there are various techniques you can use though. > > 1) Create a "lock" file when you access the database. The first thing > you do is check for its existence, create it if not there, and > delete it when you're done. You can't access the DB unless you're > the one who created the lock file. A spin on this approach, > depending on your needs and desires, is to store actual lock data > in the file, so you can lock specific records, etc. Of course, this > can just push the same problem over to the lock file rather than > the DB. > > I once was in a need of creating some locking. I did some small functions for it, and it worked good. The trick was to create some file and let it open. When other app tries to look at lock, it tries to delete it. And that is the trick which makes your app one level more robust. Because - if you don't do it that way, your app creating e.g simple db.lock file crashes, then you are left with db.lock on your harddrive and the app will not work till someone actually does not delete it manually :-)
The trouble is, that my linux friend claims, that this method is not safe under linux. I don't know, I haven't tried, but I am curious. He told me, that even if I have file opened, other process may succeed in deleting it, which seems a bit strange to me :-) > 2) Use the WinAPI (or other lib access) to "lock" part or all of the > file. If you can't acquire the lock, you can't do the work. > > 3) Check if the DB file exists, if so, rename it (so others won't find > it). When you're done, rename it back. Doesn't work if you want to > auto-create the file of course. > > 4) Use the file system as your DB, storing one record per file. Works > well for small-scale apps. From there, you can build what you want > as far as extra protection, locking, versioning, etc. Bazillions of > systems use this approach these days. > > None of these are perfect solutions. > As for simple db solutions, we have RebDB - that one is really nice small rebol based db. The trouble is, it works in memory only, and it does not solve your locking situation. Otoh you can create table called lock and check for particular record. To prevent dead locks, it would be good to register time of lock creating and regarding being unlocked if e.g. 20 min passes and the lock is not removed. But then app would have to recheck periodically, if it would need more than 20 min lock, to renew it :-) As for db which solves locking on file level, works really fast, is easy to maintain, the solution is to use sqlite, to which several drivers are available on rebol.org Sqlite is one file, no config, ultra fast on-disk database - plays well with rebol .... -pekr- -- To unsubscribe from the list, just send an email to lists at rebol.com with unsubscribe as the subject.
