Hi Stack, On Wed, May 13, 2009 at 12:26 PM, stack <[email protected]> wrote:
> 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. This could be a good approach to make the RPC thread flow. However, this would raise the number of requests (many retries) if many clients are battling for a row lock. I may ask for the more experienced: Which is better: more RPC requests or less RPC requests but their threads waiting and doing nothing? Since Ryan convinced me that my table design is faulty, I don't have an opinion on this yet. :-) > 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. > I think I didn't understand how different/better would be. Could you elaborate? Thanks Stack, Guilherme > 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 > > > -- Guilherme msn: [email protected] homepage: http://germoglio.googlepages.com
