• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

find method signature and synchronized.

 
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 531
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 531
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 32
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 197
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Anton Golovin
Ranch Hand
Posts: 531
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 197
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Oh bugger, I've overlooked this.
 
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Ranch Hand
Posts: 145
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Anton Golovin
Ranch Hand
Posts: 531
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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 ]
 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 531
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
To the original poster: abstract methods cannot be synchronized. A simple rule that has some implications...
 
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
This parrot is no more. It has ceased to be. Now it's a tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic