• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Find method data-accuracy problem.

 
Anton Golovin
Ranch Hand
Posts: 476
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, guys. The find method is straightforward to implement but calling it in business logic is very tricky. It returns an array of integers which represent matching record numbers. The natural thing to do here is to read the records specified one by one. However, there is a problem with multi-threading: after find but before read, another client may modify a found record, rendering the search inaccurate.

The most obvious solution is to lock records as they are found - locking them from within the find method! In business logic, this would necessitate unlocking a record after reading it, thus the schema becoming find/read/unlock.

There are multi-threading problems with create method as well, and in general, with any method in which the record number is not initially known. I managed to resolve the create multi-threading problem, but this find problem is pesky.

If anyone knows how to handle the issue of double-locking (synchronized find + synchronized lock called from within find) and how the system will behave when lock method has to give up the lock on Data object, please help. The alternative is, of course, to write a thread-unsafe business method for finding records, but I suspect that is where 44/80 comes into play...
[ September 01, 2004: Message edited by: Anton Golovin ]
 
peter wooster
Ranch Hand
Posts: 1033
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Anton Golovin:
Hi, guys. The find method is straightforward to implement but calling it in business logic is very tricky. It returns an array of integers which represent matching record numbers. The natural thing to do here is to read the records specified one by one. However, there is a problem with multi-threading: after find but before read, another client may modify a found record, rendering the search inaccurate.

The most obvious solution is to lock records as they are found - locking them from within the find method! In business logic, this would necessitate unlocking a record after reading it, thus the schema becoming find/read/unlock.

There are multi-threading problems with create method as well, and in general, with any method in which the record number is not initially known. I managed to resolve the create multi-threading problem, but this find problem is pesky.

If anyone knows how to handle the issue of double-locking (synchronized find + synchronized lock called from within find) and how the system will behave when lock method has to give up the lock on Data object, please help. The alternative is, of course, to write a thread-unsafe business method for finding records, but I suspect that is where 44/80 comes into play...

[ September 01, 2004: Message edited by: Anton Golovin ]


You shouldn't lock on find and read, you will not be able to prevent the displayed records from being out of date unless you lock them and leave them locked while they are displayed. If you do that you will fail for locking out all the other clients. An alternate choice is to have the server notify all clients of records that change, this is still not completely race free.

What I'm doing is providing the displayed version of the record to the book command and then doing {lock,read,compare,update,unlock}. If the compare fails, I do {refresh displayed record, unlock, notify user}. The user can then take another try or pick another record, since the likely change is that the record is now booked by someone else.
 
Anton Golovin
Ranch Hand
Posts: 476
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree. But the problem is more business-related. Some records may not be what the search specified at all. I think that is a problem, but solving this problem is more problematic than losing a few marks over it.
 
peter wooster
Ranch Hand
Posts: 1033
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Anton Golovin:
I agree. But the problem is more business-related. Some records may not be what the search specified at all. I think that is a problem, but solving this problem is more problematic than losing a few marks over it.


In my code, I ignore RecordNotFound when reading the records returned by FindByCriteria, rechecking the criteria after the read is probably a good idea, especially if you allow updates other than booking.
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 11831
181
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Anton,

I suspect that your instructions tell you that at the database level, you are doing an inexact match (possibly a "starts with" match), while at the client side you have to do an exact match.

If this is the case, then you may have to revalidate the data on the client side anyway.

Regards, Andrew
 
Anton Golovin
Ranch Hand
Posts: 476
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, that's true, it can be read that way. Thanks.
 
Marlene Miller
Ranch Hand
Posts: 1392
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How does a database query to a commercial database manage to find and return a set of records without returning any bad matches and without locking out everyone else?
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 11831
181
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Marlene,

Originally posted by Marlene Miller:
How does a database query to a commercial database manage to find and return a set of records without returning any bad matches and without locking out everyone else?


Typically the database itself does not manage this - it is up to the programmer to decide between ensuring best concurrent use of the database, or absolutely guaranteeable results.

The way the programmer does this, is by setting isolation levels. Take a look at java.sql.Connection, especially at the fields:

TRANSACTION_NONE
TRANSACTION_READ_COMMITTED
TRANSACTION_READ_UNCOMMITTED
TRANSACTION_REPEATABLE_READ
TRANSACTION_SERIALIZABLE

Sorry, I don't have a lot of time right now to go through this, but if you do a search for some of those terms (serializable, repeatable read, phantom read), you will find out some of the issues, how to solve them, and what cost is involved in solving them.

Regards, Andrew
 
Marlene Miller
Ranch Hand
Posts: 1392
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you Andrew. Those are good clues, which lead me to an introductory SQL manual that talks about data consistency and access options, and database integrity and locking. Hmmm. Marlene
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic