• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

locking upon create/delete/update

 
Lucy Sommerman
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My assign is B and S - lockRecord throws clientNotFoundException nfe.

Wondering if the create method should call lockRecord? If so, how deal with nfe - will always throw this, as record not yet created...

Also re update and delete - these take lockCookie as an argument, so I am assuming that, if these methods are ever used, lockRecord will be called first, so I do not lock, but only unlock within these methods.

This ok?

All advice appreciated.

Thanks

L
 
Lara McCarver
Ranch Hand
Posts: 118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Consider whether you really need some kind of locking for creating records. I said yes, you do for the following reason: let's say you have 2 clients and they are both creating a record at the same time. The server needs to create the records in an orderly fashion so that they go into separate rows in the database.

The next question is what kind of locking would accomplish this. You can you re-use the locking that you are doing for read/update/delete, although using it for create() might make the lock method more complicated (since it is handling more cases). The alternative is to have a separate locking mechanism for creating records. If you use the same type of locking that you are doing for read/update/delete, then your Data object is going to need to figure out what record number to use when creating a record. I think both choices are reasonable.

What I did was have my locking class implement lock(int recNo) and also lockForCreate(). As you can see, the lock() method requires a record id and the lockForCreate() doesn't.

Edit: Re-reading your original question, maybe the RecordNotFoundException that is thrown by lock() pushes you into a separate lockForCreate() method. And, I have to say that my assignment doesn't use a lock cookie, so that could change things too.
[ September 22, 2005: Message edited by: Lara McCarver ]
 
Daniel Dalton
Ranch Hand
Posts: 146
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think it depends on your design. I think there are two aspects to consider:

How to prevent data corruption caused by one thread moving a Filepointer
under the feet of a second - at least two ways to solve that, one of which
would be to synchronize access to a single file object.

The lock method deals with "logical locking" - ie. preventing two well
behaved threads from both updating the same record. If you do lock(), read,
update, unlock()
the thread might be timesliced after lock and who knows how much further I/O
other threads may do in the meantime. That's why I think it best to
at least think about the two aspects separately.

In my design, I synchronize on a single file object, which prevents two
threads adding a record at the same time, so I don't lock before create.

Hope that helps,
 
Lucy Sommerman
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
ok thanks, will go for lockforCreate() way, makes more sense to me, the way i have done things..
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic