• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Logical consistency of search results

 
Roy Mallard
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Say client A searches for all records (there are 100 records).
The search traverses the records in order starting from record 1. When the search reaches record 40, client B changes record 20. Then client C changes record 70. The search picks up the change to record 70, but not the change to record 20. Therefore the list of records that client A sees is a list that never actually existed in the database.
Would I lose marks for this or does it not matter?
 
Jeroen T Wenting
Ranch Hand
Posts: 1847
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That scenario is unavoidable.
 
Oricio Ocle
Ranch Hand
Posts: 284
Debian Firefox Browser Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Roy,
the problem you are talking about is omnipresent.
Light speed is finite so what you are really seeing is not what it is

Regards
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[Roy]: Therefore the list of records that client A sees is a list that never actually existed in the database.

If you are bothered by the fact that the list may be out of date, there's nothing really that can be done about that. However if you're bothered by the fact that the list may represent an inconsistent view of the data, in the sense that the change to record 70 happened after the change to record 20, but you only see the change to record 70... well that is avoidable, in the sense that you could use synchronization to prevent any other threads from accessing the list of records at all while the search is going on. However you should weigh the benefits against the costs. A search may be a relatively lengthy process, especially if there are many records. Do you really want to make all other clients wait until it completes before they do anything? Is it really a problem if a client sees changes in record 70 before changes in record 20? My thinking is, it's not that important. There are many systems in the world where this sort of thing may be important, and that's where the notion of tranactional integrity of databases comes in. However I don't think there's any reason to worry about this for SCJD, unless your instructions say something to make you think it's important.
 
Oricio Ocle
Ranch Hand
Posts: 284
Debian Firefox Browser Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello again Roy!
after reading Jim reply i noticed i had not understood your question.
Please ignore my stupid previous reply. (few sleeping hours)


Regards
 
Roy Mallard
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the reply Jim.

Do you really want to make all other clients wait until it completes before they do anything? Is it really a problem if a client sees changes in record 70 before changes in record 20?


Don't worry, my table is stored as a ConcurrentHashMap so I never have to block "read" requests.
I was going to implement a multi-version concurrency control system so users would always get a view of the database as it existed when the search query was submitted, but then thought it's probably more trouble than it's worth. My only concern is that it breaks the "Isolation" database property.
ACID properties
If you don't think I'll lose marks for it then I'll just do it the easy way
 
Roy Mallard
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
the problem you are talking about is omnipresent.
Light speed is finite so what you are really seeing is not what it is

You should be a philosopher
 
Oricio Ocle
Ranch Hand
Posts: 284
Debian Firefox Browser Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You should be a philosopher

I think the same at the end of the month ...
 
Robert Bar
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

Please, consider following code:





If thread is searching by criteria he must use find() followed by read().
In pessimistic case other thread is able to delete/update crucial records after find(), but before read().

Is it possible to overcome this problem?
[ June 29, 2006: Message edited by: Robert Bar ]
 
Roy Mallard
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Robert - I treat int[] find(String[] criteria) as a list of possible matches, and read each record again to make sure each one really is a match. A different client might have changed any of the records so we don't want to display incorrect search results to the user.

You could probably use synchronization to ensure the list of returned record numbers is correct, at the cost of greatly reduced concurrency.
 
Jeroen T Wenting
Ranch Hand
Posts: 1847
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Roy, that's not necessary really.
Or are you going to lock every record in the recordset you send to a client?
If you don't another client could change the record between the time your client gets it shown and the time he may decide he wants to do something with it...
 
Robert Bar
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jeroen T Wenting:
Or are you going to lock every record in the recordset you send to a client?


Jeroen, do we discuss on the same problem?

The real problem is that there is no way to perform searching and reading in thread-safe manner. In order to populate table client specifies criteria and sends a request to server. To handle the request the two methods are invoked in this order: 1. find() 2. read(), and in the pessimistic case different client is able to change or delete a record, or even delete+reuse a record's number returned by find() before read() starts!
 
Igor Kortchnoi
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Robert Bar:


The real problem is that there is no way to perform searching and reading in thread-safe manner.


What about Read/Write Lock pattern?
 
Mihai Radulescu
Ranch Hand
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Guys

I agree with Jeroen,
even if you can synchronize the read/search process (wit all the performance cost and so on) this solve only the first part of our problem - we must do something with the search result (e.g. display it).So after we leave the sync block (and try to display the result) the record list can be alter by other threads(used).

So I the answer remains 42.

But this is not so bad because a client notification mechanism goes over the developer. certification purpose.

For this cases I have a safety belt mechanism (on my middle tier). If the record is changed in between an Exception raises.

Regards, M.
 
Robert Bar
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Mihai Radulescu:
Hi Guys

I agree with Jeroen,
even if you can synchronize the read/search process (wit all the performance cost and so on) this solve only the first part of our problem - we must do something with the search result (e.g. display it).So after we leave the sync block (and try to display the result) the record list can be alter by other threads(used).

So I the answer remains 42.

But this is not so bad because a client notification mechanism goes over the developer. certification purpose.

I agree.

Originally posted by Mihai Radulescu:

For this cases I have a safety belt mechanism (on my middle tier). If the record is changed in between an Exception raises.

Regards, M.


Can you describe the situation precisely? Do you throw an Exception if record changes after searching, but before updating/deleting?
[ June 30, 2006: Message edited by: Robert Bar ]
 
Mihai Radulescu
Ranch Hand
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Guys

OK, here is my workaround.

I have a 3 tier architecture.
If an client tries to book a record he need to find it first - so he uses getAll/search method. In most of the cases the result is a list of records.
After the search is done the list is transported to the UI (and displayed). It is something like :

DB -> middle -> transport -> UI

If the client decides to book a record, he selects it and triggers the book. The middle tier still has the old record list so :
1. it locks the record (if the record was deleted in the meantime I get an Exception here) - I am shore nobody will play with this record until I am done.
2.It reads the record using the record id.
3.Compare the old record with the new one.
Now here it goes :
A.It already have a owner
B.Its content was altered
For both cases I throw exceptions.

Note : when i use the term list or record I mean more then a simple list, I think that the correct term will be a collect
ion(or map) because it stores the records and them ids but I use list for text simplicity.

What you guys think about ?

Regards M.
[ June 30, 2006: Message edited by: Mihai Radulescu ]
 
Robert Bar
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Mihai Radulescu:

B.Its content was altered
[ June 30, 2006: Message edited by: Mihai Radulescu ]


Is it really neccesary to check whether content of record was altered?

Do you have following statement in the document?

"You may assume that at any moment, at most one program is accessing the database file"

If yes, may be it is sufficient to check "owner", since application allows to update only this field?
[ June 30, 2006: Message edited by: Robert Bar ]
 
Mihai Radulescu
Ranch Hand
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Robert

I also have this part in my specs, but this does not mean that only the owner field is(can be) update, this from at least two reasons:
1.The DBMain interface provides a update method - that means in the future may bring other clients and this new clients can alter the whole record - so I'll like to remain flexible for the future clients.
2.I have my self advance client (whiteout UI) which is capable to alter the whole record.

How about the rest ? Other comments ?

Regards M
[ June 30, 2006: Message edited by: Mihai Radulescu ]
 
Jeroen T Wenting
Ranch Hand
Posts: 1847
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Robert, that only means the physical file.
It doesn't mean there will always be at most one client to the network server.

Say you had 2 clients connected to your server, both read record 10.
First client updates the record, than second client updates the record without first checking if it's changed on disk.
Now the changes by the first client are wiped out without any warning at all.
 
Robert Bar
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Mihai Radulescu:
Hi Robert

I also have this part in my specs, but this does not mean that only the owner field is(can be) update, this from at least two reasons:
1.The DBMain interface provides a update method - that means in the future may bring other clients and this new clients can alter the whole record - so I'll like to remain flexible for the future clients.
2.I have my self advance client (whiteout UI) which is capable to alter the whole record.

How about the rest ? Other comments ?

Regards M

[ June 30, 2006: Message edited by: Mihai Radulescu ]


That's what I wanted to hear - "to remain flexible".

Thanks.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic