Hello James, Well, the API seems to indicate that locking is not mandatory, since the find method doesn't require a cookie. This is one of those things you've got to decide on and justify yourself. There's a couple of issues to take into account. First, given that you don't know beforehand what records will be returned for any given search, what are you going to lock? You'd have to lock the whole database down (which I believe some here have done), and for me, the problem with this is it will reduce concurrency -- no one else can get anything done until the find completes. Note that you also have the possiblity of doing some type of synchronization that doesn't use the lock method. For example, you could use a read/write lock and read lock the database during the find. This way, other threads could read during your find, but not write until the find is complete. I like this much better than locking the whole database because it doesn't have to bring all of the other threads to a stop. This is what I'm aiming for. A last possibility is minimal synchronization. This is what I'm doing right now, but I've got a good feeling that I'm going to change it for what I mentioned in the last paragraph. My code is something like:
The above seems to work fine, and I've been sure to document the snapshot behavior in my choices.txt. Regards, jb
posted 16 years ago
Thank you, Jay. It's a good idea to maintain read and write lock! May I lock every record before I read it? Not lock the whole database?