wood burning stoves 2.0*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Troubling use case for �search� method 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 "Troubling use case for �search� method" Watch "Troubling use case for �search� method" New topic
Author

Troubling use case for �search� method

Juan Rolando Prieur-Reza
Ranch Hand

Joined: Jun 20, 2003
Posts: 236
Wondering about this case...

Assume we have to implement a method such as ��. There is no throws. And assume that the spec does not say what to do if the search method encounters a locked record.
Interpretation 1. skip locked records.
Interpretation 2. wait for record to be unlocked and then continue search.

The behavior of our implementation would be different and the wrong choice should fail some tests.
Interpretation 2 could return a record which Interpretation 1 would not.

Guidelines such as "choose the simpler approach" doesn't answer it. Both interpretations a comparably simple. Although, I would favor #1 because it offers greater concurrency.

Any thoughts?
[ September 21, 2005: Message edited by: john prieur ]

Juan Rolando Prieur-Reza, M.S., LSSBB, SCEA, SCBCD, SCWCD, SCJP/1.6, IBM OOAD, SCSA
Thomas Bigbee
Ranch Hand

Joined: Nov 29, 2001
Posts: 48
John

I say grab all the ones that currently match the criteria (except deleted and locked rows), this is the reason why...

1) You wait for a record to unlock, meanwhile someone locks a record (already in you result set) and changes a value that would have resulted in a pass by your criteria.

2) You have your result set, whilst, inspecting it, someone changes a record that would have resulted in a pass by your criteria.

3) Someone deletes a record in your result set.

4) Someone inserts a record that matches your criteria, a split second after you retireved your result set.

Basically its the eBay Syndrome, where you think you have the item, only to find out later, some dude beat you to the punch by underbidding .001 seconds before the bidding closed.

I would not worry so much about about the result set returned (there are too many variables) and instead focus upon implementing versioning (Optimistic Locking)

Tom
Samuel Pessorrusso
Ranch Hand

Joined: Jul 21, 2005
Posts: 164
Find method description:
"Returns an array of record numbers that match the specified criteria.
Field n in the database file is described by criteria[n]. A null value in criteria[n] matches any field value. A non-null value in criteria[n] matches any field value that begins with criteria[n]. (For example, "Fred" matches "Fred" or "Freddy".)" (B&S)

Pay attention to: "Returns an array of record numbers that match the specified criteria...", so my implementation doesn't care if the record is locked or not, at the method call instant the find method return array is correct (To prevent concurrent access to the record instance i use a synchronized block on it).
[ September 22, 2005: Message edited by: Samuel Pessorrusso ]
Juan Rolando Prieur-Reza
Ranch Hand

Joined: Jun 20, 2003
Posts: 236
Originally posted by Samuel Pessorrusso:
...my implementation doesn't care if the record is locked or not, at the method call instant the find method return array is correct . . . use a synchronized block on it).


Thanks for this analysis. This strengthens the approach of immediately skipping any locked records encountered. There is no explicit requirement to wait on locked records during Search.

Further thoughts� It seems that the main purpose of Optimistic Locking would be performance (speed). No objection to using it in some form, though.

Comment: synchronized block is not the only way to own the lock monitor.
Samuel Pessorrusso
Ranch Hand

Joined: Jul 21, 2005
Posts: 164
Originally posted by john prieur:
This strengthens the approach of immediately skipping any locked records encountered.


In fact I don't skip any record, my find method returns the records which data matches at that instant with the given criteria. It does not wait for locked record and does not even skip them.
Juan Rolando Prieur-Reza
Ranch Hand

Joined: Jun 20, 2003
Posts: 236
Originally posted by Samuel Pessorrusso:
[QB] ... find method returns the records which data matches at that instant with the given criteria... [QB]


Nice solution. So it seems reasonably safe to assume that the read operation is thread safe? If not...

A really cruel test engineer could substitute an IO class which deliberately gives up the CPU right in the middle of transferring bytes into your byte buffer so that another thread can write some changes to the latter part of the record. Then the GUI could display a record which matched criteria but with other fields from completely wrong data. What a hoot that would be. I was a really cruel tester in the past.
Lara McCarver
Ranch Hand

Joined: Dec 09, 2003
Posts: 118
My read method locks the record while it is reading it. Why? Because otherwise you could switch to another thread in the middle of reading the record and the other thread could lock the record, delete it, possibly even create a new record in its place. So you end up returning invalid data. Locking the record while reading it prevents all that.

So suppose that you have 5 people using the client at the same time, all doing searches (i.e. under the hood, just reads). At any one time, some of the records are going to be locked. I think it would be confusing from a UI perspective to skip these records because that means that each time you click "Search", you are going to get different results, depending on which records are locked.

Take a real life example... supposed you are buying a house and you call your mortgage broker and he does a search for loan rates for all banks. Wouldn't you be pretty upset if he didn't tell you about the lowest loan rate available just because someone else was reading it at the time? Or the travel agent didn't tell you about a sweet room in Paris because someone else was searching for hotels, too?
[ September 22, 2005: Message edited by: Lara McCarver ]
Samuel Pessorrusso
Ranch Hand

Joined: Jul 21, 2005
Posts: 164
Originally posted by Lara McCarver:
My read method locks the record while it is reading it...

Your design it is just the same of mine.


And john prieur, my read method does not have this problem because it does not perform any IO to read a record ( I have an assumption that we have a small database and I load it into the memory... that makes things easier...) I just perform IO in write operations.

my read method:
Ken Boyd
Ranch Hand

Joined: Dec 10, 2003
Posts: 329
y find method doesn't perform any lock operation. It will simply search the db file and display valid (don't show deleted record while you are doing search because it doesn't make any sense).

Now if you say while searching someone else delete or update the record then consider following

1. lock the selected record for booking
2. check if record is valid ( not deleted )
3. if everything is good go ahead and update it
4. release the lock

I think you have to perform this operation no matter your search perform read lock or not. So why to perform two lock operation.. just do it when someone want to book hotel room.

Also hotel booking and airline ticket booking works similar to this. When you search you will see many hotel rooms and flights but when you try to reserve it you get message "it is no longer available" because when you are viewing the data someone else has book the room or flight...

hope it make sense..
[ September 22, 2005: Message edited by: Ken Boyd ]

SCJP, SCWCD, SCBCD, SCJD, BB Java2 and JSP1.1
Samuel Pessorrusso
Ranch Hand

Joined: Jul 21, 2005
Posts: 164
I think we are mixing up the lock(...) with synchronized block. Sometimes we say lock trying to mean that we use a synchronized block, othertimes we say lock trying to mean that we use the provided interface lock method.
That is making this post confusing...
Juan Rolando Prieur-Reza
Ranch Hand

Joined: Jun 20, 2003
Posts: 236
Originally posted by Samuel Pessorrusso:
I think we are mixing up the lock(...) with synchronized block. Sometimes we say lock trying to mean that we use a synchronized block, othertimes we say lock trying to mean that we use the provided interface lock method.
That is making this post confusing...


Samuel, I see. It was not apparent that your solution involves an array of records, each able to be locked. Nice solution.

Lara, thanks for this analysis. Your solution seems quite appropriate.

I'm wondering about a little detail. Assume that the Search function locks records to be read. It's sure to get the latest possible update info. But it is still possible for other threads to make complete updates (del, add, etc.) between the time your Search begins and ends. Some important updates would not be presented to the GUI, and some updates would be missed (possibly). That is not really better than skipping records which are locked at the point when Search attempts to read. The record could get updated (add, del, etc) right after the Search completes its decision of whether to capture that record. In other words, if the user repeats the same query, there is no assurance that the same records will be returned. To do so would require a transaction. So, it is still a puzzlement whether its better to wait or skip.
A concern with waiting is: what if a wayward thread keeps a lock on a record for a long time. The Search method would be stuck there.

Again, thanks for your analyses.
Czarak Ynehac
Greenhorn

Joined: Sep 08, 2005
Posts: 13
Hi All,

Interesting discussion on this thread. From my reading of past expreriences with SCJD and from talking to other people who have taken SCJD in my company I have formed an opinion on this for my own project. People's requirements for their projects may be different from mine.

In the context of my situation, dirty reads are perfectly acceptable. There is no requirement in my instructions to say something else must be put in place. As has been mentioned elsewhere in this thread I think it is common even in commercial systems for information to be displayed in a gui to be out of date with the physical storage. It is when you try to act (modify/delete) on the data displayed in the gui that you get two situations:

The record you want to modify is still the same on the physical storage as it is displayed in the gui, go ahead and act on the data.

The record you want to modify has changed on the physical storage compared to what is displayed in the gui, warn the user and prompt the user to perform another search.

In the context of my situation I believe when searching the database all records should be returned irrespective of whether they are locked or not. The only records not returned are ones marked as deleted.

Best Regards,

Czarak.


"Life is like playing a violin in public and learning the instrument as one goes on."<br /> <br /> - Samuel Butler
Juan Rolando Prieur-Reza
Ranch Hand

Joined: Jun 20, 2003
Posts: 236
Originally posted by Czarak Ynehac:
... dirty reads are perfectly acceptable ...


Czarek,
Thanks for this great information. I'll just mention for the benefit of others, about terms borrowed from RDBMS technology:

"dirty read" (uncommitted read) allows data to be updated, added or deleted during the read, simply speaking.

"committed read" prevents seeing updates, adds, deletes in progress, but it is still possible for records to appear or disappear between one search and the next within a transaction. These are called phantoms. But at least the phantom records can be expected to contain self-consistent data, which uncommitted reads do not prevent.

Perhaps the SCJD does not require us to be concern with these issues. But this is a learning exercise as well.

Another point-of-view about production systems would be that "uncommitted read" should not be allowed, even if a subsequent attempt to update that record is prevented (as you mentioned, the "same" record is then required.) RDBMS products often provide default behavior such as Committed Read, or the higher Repeatable Read isolation levels.

I feel that SCJD should expect the behavior comparable to Committed Read, to demonstrate our capability and intention to provide good common practices using the java platform.

Thank you very much for your great useful thoughts, everyone.
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11526
    
100

Hi everyone,

My thoughts are in "Why are dirty reads ok?" so I won't repeat them here.

Regards, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Juan Rolando Prieur-Reza
Ranch Hand

Joined: Jun 20, 2003
Posts: 236
Originally posted by Czarak Ynehac:
... dirty reads are perfectly acceptable ...


Your asking about dirty reads and so forth seems perfectly reasonable for learning about issues raised by the SCJD. These terms are not the exclusive property of Transactions technology.

I guess the examiners will not be so exacting as to require prevention of updating records by another thread. But we may be expected to justify our choices that allow phantoms and corrupt records (or not).

Cheers, and thanks for all the fine feedback.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Troubling use case for �search� method