A Share or Exclusive lock gives implicit locks on all child resources.  The tx does not need to request those locks explicitly.


Intention locks are different.  E.g., a SIX lock gives a Share locks but requires explicit locking of child resources in exclusive mode.




From: jdbm-developer-admin@lists.sourceforge.net [mailto:jdbm-developer-admin@lists.sourceforge.net] On Behalf Of Kevin Day
Sent: Wednesday, March 29, 2006 8:14 PM
To: JDBM Developer listserv
Subject: re[8]: [Jdbm-developer] re[14]: 2PL: transactions, threads <s nip>




Can you help me understand the concern on memory usage?  In reading the paper on granular locks, the lowest level resource that is going to be worked with still has to be locked.  In the normal operation of jdbm, operations are performed at the record level, so this would be the natural locking level.


In the Gray paper, even, they show locking down the record level....  How is running 2PL without intention locking going to increase memory usage?


- K




> If people want to use 2PL without intention and implicit locking, then there are various consequences.  First, the memory burden is much higher since each individual resource requires its own queue to manage locking.  Second, there is an increased likelihood of deadlock since you can not use intention locks to coordinate locking over a child resources, which in turn reduces concurrency. <


------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Jdbm-developer mailing list Jdbm-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jdbm-developer