Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Nx: Update Problem

 
Jonathan Pengelly
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi everyone,
I am having trouble with the following situation -
Client A books record X.
Client B has not had his JTable updated since Client A booked record X so still thinks that record X has not been booked. Client B then books record X as well thus overwriting client A's booking.
I have been struggling to think of a solution. All of my locking code is in the data.java class and so it seems that there will always be the chance that two clients will interact in this way and IMO this is not good application behavior because it doesn't inform users of changes since their client's last recordset update.
Does anybody have any comments about this issue?
Thanks
Jonathan
 
Jonathan Pengelly
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,
I have an additional comment to make regarding this issue. I have looked through some of the other posts and have noticed people talking about their Book methods following this structure -
i) Lock Record
ii) Refresh Record (thus checking to see if it has changed)
iii) Update Record
iv) Unlock Record
This sounds perfect, however I have implemented locking within the update and read methods themselves. Is this a poor decision?
I agree that with a structure for my booking method like above then the updating problem referred to in my first post is not an issue but if this is the case then I think I need to revise my locking code.
Any comments?
Thanks,
Jonathan
 
George Marinkovich
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jonathan Pengelly:
I am having trouble with the following situation -
Client A books record X.
Client B has not had his JTable updated since Client A booked record X so still thinks that record X has not been booked. Client B then books record X as well thus overwriting client A's booking.
Does anybody have any comments about this issue?

Hi Jonathan,
How about:
Client B obtains a lock on record X
Client B reads record X (gets the latest value for X from the database)
Client B no longer thinks that record X was unbooked since he sees Client A's update
Client B decides whether or not to update record X
Client B releases lock on record X
For more discussion on this topic see Topic: NX:Locking - one data instance or multiple It's a wide ranging thread, the relevant portions are toward the bottom I think.
Hope this helps,
George
 
George Marinkovich
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jonathan,
Our posts crossed in the ether. I didn't see your latest post until now.

This sounds perfect, however I have implemented locking within the update and read methods themselves. Is this a poor decision?

There are no poor decisions, only decisions that lead to problems that have to be overcome.
One of the reasons I like my decision is that I can handle stale records in the JTable in an easy manner. It's no doubt possible to handle things properly by following the path you're on, but you may have to overcome some problems that may crop up. Since I didn't go down that path I'm probabaly not the best person to make suggestions in this regard. I'm sure others have made the same choice as you, and maybe they'll be willing to discuss how they overcame the stale record problem in their schemes.
Hope this helps,
George
 
Jonathan Pengelly
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks George.
Yep. I understand that the lock / refresh and check / update / unlock flow of logic for the book method will solve this problem. However, if I am using the lock methods in my adaptor class does that mean that I should not be using them at all in my data class because they might conflict with each other?
This is because I have currently used the lock and unlock methods within the delete, create, update and read methods and I get the feeling that this might be where the problem is.
Regards,
Jonathan
[ January 17, 2004: Message edited by: Jonathan Pengelly ]
 
George Marinkovich
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jonathan,
Ok, yes, you dragged it out of me, I think that locking and unlocking does not belong within the other database operations in Data. If it were intended to be there then the lock, unlock, and isLocked methods should be private rather than public. But this is only my opinion. I'm sure some people have done it the way you're doing it and I'm sure they got it to work (somehow).
There are good reasons to do what you've done. Basically you prevent a user from doing any of the database operations in Data without paying attention to locking. I merely make a comment in my code saying a client should only call these methods according to the locking protocol of lock/database_operation/unlock. Obviously prevention trumps suggestion every time.
I think I started out on your path and ran into some of the problems that you're seeing, such as wanting to do a sequence of database operations (read and update) that could not be interrupted by another client. I think those problems made me rethink my design and caused me to make lock, unlock, and isLocked full-fledged public members of Data. The choice is yours. As I've said there are some aspects of it that I think are superior to my approach, but I didn't see how to easily overcome some of the problems so I retreated, regrouped, and lived to fight another day. I'm the wrong person to give advice about how to get around problems in your approach, because the solution to those problems was not obvious to me, which is why I abandoned that approach in favor of another.
I'm sure someone out there has solved this problem using your approach. Let them come forward and explain how they did it.
Hope this helps,
George
[ January 17, 2004: Message edited by: George Marinkovich ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic