• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

GUI search by findByCriteria and readRecord: synchronize?

 
Jeroen Kema
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi SCJ developers,

I'm developing at my URLyBird 1.2.3 assignment, and I have a question about the GUI search functionality.

I've created a Service layer between the GUI and the Data interface. This service layer has a method named findByNameAndLocation. Roughly, the implementation of this method is as following: at first the Data.findByCriteria methodis called to find the matching record numbers, and after that for every record number the Data.readRecord method is called to get the data.

Now I'm in doubt about what to do with the situation that between the invocation of findByCriteria and readRecord another thread could manipulate one of the founded record numbers.

1. Must I take into account that an updateRecord or deleteRecord could manipulate/delete a record that has just been found by findByCriteria, which means that the result of readRecord could be unexpected (i.e. RecordNotFound or altered name/location data)?

2. Do I have to synchronize the findByCriteria and readRecord calls in my Service class? Keep in mind that the calls of both methods are interface calls, so the user does know nothing about synchronization of the Data implementation.

I hope you can help me with these questions!

Regards,

Jeroen
 
Alecsandru Cocarla
Ranch Hand
Posts: 158
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'd say option 1. Otherwise, while the modifying thread waits, you find the records, everything is perfect. But, immediately after, the modifying thread comes into action and performs the changes anyway. So the user will receive a non-updated (outdated) version of the records. Unless you implement some notifying mechanism, from the server to the client, there's no way you can avoid this. So no need to synchronize anything, you're just making your life harder.

What I did is show the booked record to the user, before and after the booking succeeded, such that the user can decide if he booked the expected record or not.
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeroen,

maybe another alternative could be: maybe you can implement in the Data-class a method like


which does the regular find and for every record number does a read.

so your service method will call this method and you have all info needed

just a thought
Kind regards,
Roel
 
Jeroen Kema
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Alecsandru Cocarla wrote:I'd say option 1. Otherwise, while the modifying thread waits, you find the records, everything is perfect. But, immediately after, the modifying thread comes into action and performs the changes anyway. So the user will receive a non-updated (outdated) version of the records. Unless you implement some notifying mechanism, from the server to the client, there's no way you can avoid this. So no need to synchronize anything, you're just making your life harder.


There is a big difference between data manipulation between findByCriteria and readRecord and data manipulation after a synchronized execution of findByCriteria and readRecord. In the first situation, the following could occur (in pseudo-code):

Thread-1: service.searchHotelRooms(location = "New York")
Thread-2: lockRecord(1);
Thread-1: findByCriteria({..,..,"New York",..}) returns record number 1.
Thread-2: updateRecord(1, {..,..,"Washington",..}, cookie);
Thread-1: readRecord(1) returns a HotelRoom with location = Washington.

In this situation, the user asks for hotelrooms in New York, but gets a hotelroom in Washington. I think you should call this a bug. What you mentioned, that the record could be manipulated immediately after the service.findHotelRoom() has finished, is not really a problem because this is something you can handle by checking if the record on the client is still up to date.

What I did is show the booked record to the user, before and after the booking succeeded, such that the user can decide if he booked the expected record or not.

I think this is something that should be checked by the system, not by the user.

Roel De Nijs wrote:Jeroen,

maybe another alternative could be: maybe you can implement in the Data-class a method like


which does the regular find and for every record number does a read.

so your service method will call this method and you have all info needed

just a thought
Kind regards,
Roel


You mean that you create an extension to the DBAccess interface? Something like:



Is this a solution that will be accepted by Sun? I ask this, because the DBAccess interface may not be altered.
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You may not alter the given interface, and data must implement the sun's interface

so if you extend the given interface and add an extra method, you are not altering the given interface. if Data implements the extended interface, it's also implementing the given interface. so you are not violating the specs

and many people have extended the db-interface and passed the exam, e.g. this javarancher

I also extended the given interface (but i have still a long way to go before knowing if i could pass with that approach)


 
Alecsandru Cocarla
Ranch Hand
Posts: 158
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeroen Kema wrote:
In this situation, the user asks for hotelrooms in New York, but gets a hotelroom in Washington. I think you should call this a bug. What you mentioned, that the record could be manipulated immediately after the service.findHotelRoom() has finished, is not really a problem because this is something you can handle by checking if the record on the client is still up to date.

This won't happen. You forgot a step here: findByCriteria won't give youthe exact matches, but the startsWith matches. But you need to return exact matches. So the last step is not "read record and return", it is "read record, check exact match, return".

Jeroen Kema wrote:
I think this is something that should be checked by the system, not by the user.

Well, have fun implementing this system check... And good luck!
 
Jeroen Kema
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Alecsandru Cocarla wrote:
Jeroen Kema wrote:
In this situation, the user asks for hotelrooms in New York, but gets a hotelroom in Washington. I think you should call this a bug. What you mentioned, that the record could be manipulated immediately after the service.findHotelRoom() has finished, is not really a problem because this is something you can handle by checking if the record on the client is still up to date.

This won't happen. You forgot a step here: findByCriteria won't give youthe exact matches, but the startsWith matches. But you need to return exact matches. So the last step is not "read record and return", it is "read record, check exact match, return".

Hmm, I've forgotten the exact match thing... This is also a good solution for this problem. Thanks for mentioning
Alecsandru Cocarla wrote:
Jeroen Kema wrote:
I think this is something that should be checked by the system, not by the user.

Well, have fun implementing this system check... And good luck!

You sound a little bit irritated, I hope I'm wrong. Do you think implementing this check is too complex?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic