File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes NX (contractors): find() and dirty reads Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "NX (contractors): find() and dirty reads" Watch "NX (contractors): find() and dirty reads" New topic

NX (contractors): find() and dirty reads

Rob Zidsen

Joined: Jul 07, 2003
Posts: 16
To prevent dirty reads and such, would you guys recommend locking the whole database when performing find()? This would prevent one thread from changing a record in the middle of another thread searching through the whole database to find matching records. On the other hand, this may cause clients to appear to hang if there are too many calls to find() and the database is large.
Jim Yingst

Joined: Jan 30, 2000
Posts: 18671
Well, speaking as someone who routinely complains about the possibility of dirty reads elsewhere - I think that the find() method is the place where dirty reads are most acceptable. The find() method is probably the slowest, most I/O-intensive and/or CPU-intensive method of the API. If you ever sacriface accuracy (potentially) for speed, this is the place to do it. Locking the DB for the dureation of find() sounds like it's going to slow things pretty badly - I'd try to avoid it. Accepting dirty reads is one way to achieve this. There are other possibilities though. E.g. if each individual read or write is atomic, then you don't really need to lock the whole database. Also, if you keep all the data in memory rather than having to read a file, then the whole search can be done much quicker. (The downside is, what if youdon't have enough memory? Personally I find this unlikely, but most others have avoided all-in-memory for this reason). I'm not going to get into all the ways atomicity and locking can be achieved; that's a long discussion, and you can read lots of other posts about different options. But I'd say that dirty reads are acceptable for find() at least. Maybe with read() too.
Note that because of the way find() works, there's going to be a (tiny) delay between find()ing the row numbers, and read()ing the actual rows. During this interval, record values could be updated. So even if find() returns perfect results, the read() values may show you something slightly different. I think you just have to accept this possibility. Maybe do some additional filtering client-side to ensure that only valid search results are displayed. Which you may need to do anyway for other reasons, such as the slight mismatch between GUI requirements and the DB find() API. The GUI wants exact matches; find() uses startsWith(). So you may need to tweak the results of your find() anyway.
[ August 15, 2003: Message edited by: Jim Yingst ]

"I'm not back." - Bill Harding, Twister
I agree. Here's the link:
subject: NX (contractors): find() and dirty reads
It's not a secret anymore!