aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes find method signature and synchronized. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "find method signature and synchronized." Watch "find method signature and synchronized." New topic
Author

find method signature and synchronized.

lydie prevost
Ranch Hand

Joined: Mar 14, 2002
Posts: 32
Hello,

I have a question concerning my fing method in data. I want to add "synchronized" but the find method in DB interface is not synchronized.
My understanding is that "synchronized" does not change the signature of a method. So I am OK to have it synchronized in Data even if it is not in the inteface.
Or should I wrap find in synchronized find method?
What do you think?
- Thank you

- Lydie
Anton Golovin
Ranch Hand

Joined: Jul 02, 2004
Posts: 476
Originally posted by lydie prevost:
Hello,

I have a question concerning my fing method in data. I want to add "synchronized" but the find method in DB interface is not synchronized.
My understanding is that "synchronized" does not change the signature of a method. So I am OK to have it synchronized in Data even if it is not in the inteface.
Or should I wrap find in synchronized find method?
What do you think?
- Thank you

- Lydie


We are free to synchronize a method. It does not change its signature.


Anton Golovin (anton.golovin@gmail.com) SCJP, SCJD, SCBCD, SCWCD, OCEJWSD, SCEA/OCMJEA [JEE certs from Sun/Oracle]
Anton Golovin
Ranch Hand

Joined: Jul 02, 2004
Posts: 476
There is another problem that I encountered with the find method, and which I would like to share with you. In multi-threaded application, the numbers that the find method returns are not guaranteed to be the matching records when they are read one by one from the database. So basically your business method (findRoom) will have to recheck the records against the criteria to make sure they are ok. It is a good place to turn partial matches (as required by the DB interface) into exact matches, as required by the client.

Not to the topic, maybe, but it should be useful
lydie prevost
Ranch Hand

Joined: Mar 14, 2002
Posts: 32
I am not sure I got what you said...
Did you mean that by the time you do anything with the"list" of contractors/books some other thread could have altered it, So you have to check it again?
So when does this stop? , because this same thing could possibly happen again and again! Unless you locked the file/database you are never sure of accessing the right data.
How can we get around of this?
The more I think of the locking scheme the more I am lost........
- Lydie
mike acre
Ranch Hand

Joined: Sep 23, 2003
Posts: 197
Pay no heed to records being out of date, find() then read() for each recNo.
This will be very simple like you have said, 'when does this stop'. Don't even start it! When the very best you could hope for is that the returned collection is out of date the minute it is displayed in the table. So what?! It does not change anything, it is for this reason that crucial update operations should do a lock, read, check, update, unlock cycle. These are just the unavoidable side effects of a multi user system.


SCJP 1.4, SCJD
Anton Golovin
Ranch Hand

Joined: Jul 02, 2004
Posts: 476
Well, no, the problem is not that the collection is out of date, but that some records as retrieved may not match the search criteria. Consider the following:

your findRoom method may have:


synchronized find is called. an array of record numbers is returned.
synchronized read is called for each record.

If more than one client is accessing the database, something could happen between the find and the read for a record. That record may be a) deleted, b) deleted, then modified (overwritten), c) just modified (booked).

The a) option is handled by the RecordNotFoundException of the read method.
But what about the b) and c) options? It could result in the record displaying data which does not match the search criteria! What the findRoom method could be doing is returning wrong data to the client.

This is solved by rechecking a read record for matching the search criteria. We do not care if the record is out of date once it is passed to the client. It cannot be helped. But we do care that all the records passed to the client match the search criteria. And that is why every record needs to be rechecked.

There is an added benefit in that if you are writing a thin client. When you are rechecking the record in the business logic, it is returned on a partial match, as specified in the DB interface. Yet, the client is expected to show only complete matches (or complete matches on one of the criteria.) The business logic is the perfect place to achieve that. So my code a) rechecks the record matches the criteria, and b) checks that the record has at least one parameter which exactly matches criteria's parameter.

Sorry if I did not make myself clear the first post.

BTW, locking is achieved by only a few lines of code. Don't worry about it, you will get it done.
[ September 20, 2004: Message edited by: Anton Golovin ]
mike acre
Ranch Hand

Joined: Sep 23, 2003
Posts: 197
Oh bugger, I've overlooked this.
peter wooster
Ranch Hand

Joined: Jun 13, 2004
Posts: 1033
Originally posted by mike acre:
Oh bugger, I've overlooked this.


Its not a big deal, the business logic could provide a second filtering to remove possibly invalid data, but since all you can do is book, the only invalid information is that the room may appear to be free when it isn't. If there are clients out there that can modify the name and location or delete the record then you may end up displaying truly invalid data. The final filtering must be done when booking is attempted and must be the sequence you described.
Andy Zhu
Ranch Hand

Joined: May 26, 2004
Posts: 145
I think Peter is to the point. search is not critical, booking is where we need to check record again. As to Anton's half read, I think I will just leave it as is, since there really is no reason to lock.


--------<br />Andy Zhu<br />scjp 1.4<br />scjd 1.4<br />SAS Certified Programmer 9.0
Anton Golovin
Ranch Hand

Joined: Jul 02, 2004
Posts: 476
Originally posted by peter wooster:


Its not a big deal, the business logic could provide a second filtering to remove possibly invalid data, but since all you can do is book, the only invalid information is that the room may appear to be free when it isn't. If there are clients out there that can modify the name and location or delete the record then you may end up displaying truly invalid data. The final filtering must be done when booking is attempted and must be the sequence you described.


Actually, if the record is deleted, then overwritten, the record may be from a different city, different hotel, etc. It is no big deal, easy to catch, but it was good to combine the exact-matching and eliminating an occasional bad record, so I did it.

Basically, the hypothetical situation is:

1) find record n to partially match...

2) but before reading record n, another thread deleted it, and yet another overwrites it.

3) now read record n, but what is read is completely non-matching data.

So needs to be checked at findRoom for matching again. Can be combined to check for exact matching this time.

P.S. But when the client can only book, then this is irrelevant. Like Peter wrote, only c) can apply from my post above, and that is probably handled in a different piece of code in the method.
[ September 20, 2004: Message edited by: Anton Golovin ]
Bubba Smith
Greenhorn

Joined: Sep 12, 2004
Posts: 5
in the fbns spec they ask to implement a locking on the whole db.
could you not just write lock the db before your search and unlock it after reading the data and not have any headaches w/ invalid data? performance aside.
Anton Golovin
Ranch Hand

Joined: Jul 02, 2004
Posts: 476
Originally posted by peter wooster:


Its not a big deal, the business logic could provide a second filtering to remove possibly invalid data, but since all you can do is book, the only invalid information is that the room may appear to be free when it isn't. If there are clients out there that can modify the name and location or delete the record then you may end up displaying truly invalid data. The final filtering must be done when booking is attempted and must be the sequence you described.


This discussion has been really useful. For some reason, I put record-data validation into the update method itself. Now I moved it to the right place.
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11478
    
  94

Hi Bubba,

Originally posted by Bubba Smith:
in the fbns spec they ask to implement a locking on the whole db.
could you not just write lock the db before your search and unlock it after reading the data and not have any headaches w/ invalid data? performance aside.


You would loose a lot on your concurrency - especially if the data file grew to a reasonable size and you had a large number of clients. That alone would cost you a few marks I suspect. Much better to solve the issue than to risk the few marks (IMHO).

Regards, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Robert Chisholm
Ranch Hand

Joined: Jul 18, 2004
Posts: 69
To the original poster: abstract methods cannot be synchronized. A simple rule that has some implications...


SCJP 1.4<br />(WIP) SCJD B&S v2.3.3
Joakim Eriksson
Greenhorn

Joined: Sep 13, 2004
Posts: 25
Originally posted by Anton Golovin:
Well, no, the problem is not that the collection is out of date, but that some records as retrieved may not match the search criteria. Consider the following:

your findRoom method may have:


synchronized find is called. an array of record numbers is returned.
synchronized read is called for each record.

If more than one client is accessing the database, something could happen between the find and the read for a record. That record may be a) deleted, b) deleted, then modified (overwritten), c) just modified (booked).

The a) option is handled by the RecordNotFoundException of the read method.
But what about the b) and c) options? It could result in the record displaying data which does not match the search criteria! What the findRoom method could be doing is returning wrong data to the client.

This is solved by rechecking a read record for matching the search criteria. We do not care if the record is out of date once it is passed to the client. It cannot be helped. But we do care that all the records passed to the client match the search criteria. And that is why every record needs to be rechecked.

There is an added benefit in that if you are writing a thin client. When you are rechecking the record in the business logic, it is returned on a partial match, as specified in the DB interface. Yet, the client is expected to show only complete matches (or complete matches on one of the criteria.) The business logic is the perfect place to achieve that. So my code a) rechecks the record matches the criteria, and b) checks that the record has at least one parameter which exactly matches criteria's parameter.

Sorry if I did not make myself clear the first post.

BTW, locking is achieved by only a few lines of code. Don't worry about it, you will get it done.

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


Basically this means the find method is useless unless you lock the whole database before reading the records.
Why not retrieve the record at once via a better search method? Why return the int[] array at all? It is in my Data.java class because it is required, but I don't use it all because of the reasons you mention.

Instead I implement a new search method in the adapter using a query TO (yes a Transfer Object) it can hold all kinds of details on the query, like: only show bookable entries, match exact or match partial etc...
The results (rows of the database or ValueObjects) are then read into an array. This array is dubbed "ValueObjectTO". Passing all data back in one object is preferrable because it reduces network traffic. (cf. doing a search and multiple reads from the client).
As I pass the match directly into the VOTO it is still a match when presented to the client even if the record is stale because of a modify op the millisecond after I read it (synchronized).

Updates passes along the VO I want to change, locks it record, performs a comparison, notifies the client if it is stale or else performs the update and returns. The record is then unlocked in the finally clause.

Easy and stateless solution.

(It only took me a month or so to finally agree with myself that it was better than using cache, timestamps, and what-not.).

/J
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: find method signature and synchronized.