SCJP, SCWCD, SCBCD, SCJD, BB Java2 and JSP1.1
Locking
Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the interface provided above. You may assume that at any moment, at most one program is accessing the database file; therefore your locking system only needs to be concerned with multiple concurrent clients of your server. Any attempt to lock a resource that is already locked should cause the current thread to give up the CPU, consuming no CPU cycles until the desired resource becomes available.
SCJP, SCWCD, SCBCD, SCJD, BB Java2 and JSP1.1
Does that say loud enough that I should not worry about problem I mention in recent thread (link provided) that one client won't try to lock multiple records and creates deadlock..
Originally posted by Eric Janssens:
The Data interface is just the common interface to access the database shared by all the applications in the company. You do not need to put everything there. You can always prevent multiple locks for one client at any upper level in your application.
Cookie1 = lockmanager.reserveRoom(recNo);
update (record 10,Cookie1);
Cookie2 = lockmanager.reserveRoom(recNo);
update (record 11,Cookie2);
unlock(record10, Cookie1);
unlock(record11, Cookie2);
Cookie1 = lockmanager.reserveRoom(recNo);
update (record 11,Cookie1);
Cookie2 = lockmanager.reserveRoom(recNo);
update (record 10,Cookie2);
unlock(record11, Cookie1);
unlock(record10, Cookie2);
Cookie1 = lockmanager.reserveRoom(recNo);
update (record 10,Cookie1);
unlock(record10, Cookie1);
Cookie2 = lockmanager.reserveRoom(recNo);
update (record 11,Cookie2);
unlock(record11, Cookie2);
SCJP, SCWCD, SCBCD, SCJD, BB Java2 and JSP1.1
SCJP, SCWCD, SCBCD, SCJD, BB Java2 and JSP1.1
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime. |