Guilherme: Thinking on this a little more, maybe if a batch update or a check and save carried a lock, instead of our having the RPC park waiting on the row lock to be released occupying resources -- rpc thread, etc. -- that instead, we should ask the lock if its already taken and if it is, throw a new RowLockedException.
Clients getting the new RLE would do the usual retrying logic failing if they can't get the lock after N retries. See http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/locks/ReentrantReadWriteLock.html . Would be sweet if the lock testing only happened when client offered a RowLock so usual case didn't have to suffer this test. If you make a patch, we'll commit it (smile). Thanks G, St.Ack On Tue, May 12, 2009 at 10:10 PM, stack <[email protected]> wrote: > On Sun, May 10, 2009 at 10:19 AM, Guilherme Germoglio <[email protected] > > wrote: > >> >> Hi Stack, >> >> Is the rowlock parameter in checkAndSave mandatory? Or can it be null? If >> it >> can't be null, I'll probably have the problem of many lockRow() calls as >> well. > > > > It doesn't look mandatory looking at code. > St.Ack >
