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

One Client Locking Multiple Records

 
Javini Javono
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
quote:

Originally posted by Sai Prasad:
Just one comment about Peter's posting. At any moment in this locking process,
any one client will be associated with only one lock.

--------------------------------------------------------------------------------
Peter den Haan
bartender and author
Member # 862
posted April 10, 2002 02:20 AM ��� �� �� �� �� � � ��
That is a dangerous assumption to make, especially in view of the reusability
requirements for the database implementation. Surely future applications making
use of the database might well need multiple locks.
But, as I said above, there is more than one "right" design, and making this
assumption is unlikely to prevent you from passing the exam provided you set out
your reasoning in the design documentation.
- Peter
[ April 10, 2002: Message edited by: Peter den Haan ]
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------

Hi,
Here is how multiple locking to mutate a set of records would work:
1. A business method sequentiall locks down records from the lowest
record to the highest record. If any record it attempts to lock is already
locked, it wait()'s on that record as usual via the LockManager. Because the
records are not circular (like the dining philosophers), dead-lock is not
possible.
2. The business method proceeds to book each locked record. If it
finds that one record is booked, then it unbooks any records it has
booked and gives up.
3. If the business method succeeds in booking all the requested records,
then they remain booked and the customer is informed of this.
However, this must be considered along with this:
if you LockManager is set up so that the client ID is the key to a hash table,
then it becomes impossible for one client to lock more than one record at a
time.
But, a "LockManager" can be plug and play; so, you might start off with one
lock manager, describe its limitations, and say that another LockManager
can be implemented when, and if, a client holding locks to more than one
record becomes a requirement.
Thanks,
Javini Javono
P.S. Having one client lock multiple records is not a project condition.
[ February 15, 2004: Message edited by: Javini Javono ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic