Return-Path: Delivered-To: apmail-jakarta-commons-user-archive@www.apache.org Received: (qmail 5548 invoked from network); 7 Jul 2005 11:43:28 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 7 Jul 2005 11:43:28 -0000 Received: (qmail 84124 invoked by uid 500); 7 Jul 2005 11:43:18 -0000 Delivered-To: apmail-jakarta-commons-user-archive@jakarta.apache.org Received: (qmail 84067 invoked by uid 500); 7 Jul 2005 11:43:18 -0000 Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Jakarta Commons Users List" Reply-To: "Jakarta Commons Users List" Delivered-To: mailing list commons-user@jakarta.apache.org Received: (qmail 84054 invoked by uid 99); 7 Jul 2005 11:43:18 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 07 Jul 2005 04:43:18 -0700 X-ASF-Spam-Status: No, hits=0.2 required=10.0 tests=NO_REAL_NAME X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [170.11.40.15] (HELO minnesotamutual.com) (170.11.40.15) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 07 Jul 2005 04:43:06 -0700 Received: from ([170.11.184.70]) by mmsctmailp1.minnesotamutual.com with ESMTP id KP-KZ276.54976392; Thu, 07 Jul 2005 06:42:38 -0500 Received: from mmlnts03.mmacct.root.mds ([170.11.192.142]) by mmlnts10.minnesotamutual.com (Lotus Domino Release 6.0.3) with ESMTP id 2005070706423663-104624 ; Thu, 7 Jul 2005 06:42:36 -0500 In-Reply-To: <9da4f4520507070047351d8ec@mail.gmail.com> Subject: Re: Transaction API, ReadWriteLock - RESOLVED To: "Jakarta Commons Users List" X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: LeRoy.Yanta@securian.com Date: Thu, 7 Jul 2005 06:42:34 -0500 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on MMLNTS03/Minnesota Mutual(Release 6.0.2CF1|June 9, 2003) at 07/07/2005 06:42:36 AM, Itemize by SMTP Server on MMLNTS10.minnesotamutual.com/Minnesota Mutual(Release 6.0.3|September 26, 2003) at 07/07/2005 06:42:36 AM, Serialize by Router on MMLNTS10.minnesotamutual.com/Minnesota Mutual(Release 6.0.3|September 26, 2003) at 07/07/2005 06:42:38 AM, Serialize complete at 07/07/2005 06:42:38 AM Content-type: text/plain; charset=US-ASCII X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Oliver, Thanks for your help on this issue. LeRoy Oliver Zeigermann To Jakarta Commons Users List 07/07/2005 02:47 AM cc Subject Please respond to Re: Transaction API, ReadWriteLock "Jakarta Commons Users List" Yes, all participating threads would need to access the same transaction manager. Oliver On 7/6/05, LeRoy.Yanta@securian.com wrote: > > > > > > Switching to use a manager to manage lock references eliminates the need to > mange lock references, but doesn't this just push this reference problem to > the manager object? > > If classes foo1 and foo2 needed to write to the same file, they would need > to reference the same manager object to be aware of the lock that was > created by the other class. If so, then the creation of the manager object > would need to be placed in Singleton object so both classes could obtain > the same reference to the manager object. Correct? > > LeRoy > > > > > > > Oliver Zeigermann > n@gmail.com> To > Jakarta Commons Users List > 07/06/2005 09:47 > AM cc > > Subject > Please respond to Re: Transaction API, ReadWriteLock > "Jakarta Commons > Users List" > arta.apache.org> > > > > > > > Exactly. In most cases I would recommend to use a manager. > > Oliver > > On 7/6/05, Aaron Hamid wrote: > > I see, so if I do not wish to manage the lock references myself, I (and > LeRoy also) should always obtain locks through a LockManager. > > > > Aaron > > > > Oliver Zeigermann wrote: > > > By the way, when giving me first advice I stumbled over exactly this > > > difference between the lock manager and the lock itself... > > > > > > Oliver > > > > > > On 7/6/05, Oliver Zeigermann wrote: > > > > > >>You are right, but only for the lock manager. The lock manager takes > > >>care of uniquely mapping a resource id to a lock, but when you work on > > >>a lock *directly* it must - of course - be the same object. > > >> > > >>Oliver > > >> > > >>On 7/6/05, Aaron Hamid wrote: > > >> > > >>>Is this true? It was my impression, have first written such a class, > and then finding and skimming the javadoc for [ReadWrite]LockManager, and > particularly 'getLock' and 'createLock', that lock singletons would be > automatically created and managed. Otherwise the developer must write a > lot of boilerplate code for keeping a singleton map of locks. Surely only > the 'resourceId' must be the same, and not the actual ReadWriteLock > reference? > > >>> > > >>>LockManager: "Encapsulates creation, removal, and retrieval of locks. > Each resource can have at most a single lock." > > >>> > > >>>Aaron > > >>> > > >>>Oliver Zeigermann wrote: > > >>> > > >>>>Ooops, sorry, you are right. Not only the resource Id, but the lock > > >>>>*itself* must be the same in both threads. > > >>>> > > >>>>Doing it this way: > > >>>> > > >>>> final ReadWriteLock fileLock = new > ReadWriteLock("Huhu", loggerFacade); > > >>>> Runnable run = new Runnable() { > > >>>> > > >>>> public void run() { > > >>>> > > >>>> try { > > >>>> System.out.println("before > acquiring a lock " > > >>>> + > Thread.currentThread()); > > >>>> boolean result = > fileLock.acquireWrite(Thread > > >>>> > .currentThread(), Long.MAX_VALUE); > > >>>> System.out.println("lock > result: " + result + " " > > >>>> + > Thread.currentThread()); > > >>>> Thread.sleep(20000); > > >>>> System.out.println("after > sleeping " > > >>>> + > Thread.currentThread()); > > >>>> } catch (InterruptedException e) { > > >>>> e.printStackTrace(System.err); > > >>>> > > >>>> } finally { > > >>>> > fileLock.release(Thread.currentThread()); > > >>>> } > > >>>> } > > >>>> > > >>>> }; > > >>>> > > >>>> Thread t1 = new Thread(run, "Thread1"); > > >>>> Thread t2 = new Thread(run, "Thread2"); > > >>>> t1.start(); > > >>>> try { > > >>>> Thread.sleep(1000); > > >>>> } catch (InterruptedException e) { > > >>>> } > > >>>> t2.start(); > > >>>> > > >>>> > > >>>>works fine for me. > > >>>> > > >>>>HTH > > >>>> > > >>>>Oliver > > >>>> > > >>>>On 7/6/05, LeRoy.Yanta@securian.com wrote: > > >>>> > > >>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>>Oliver, > > >>>>> > > >>>>>I tried your suggestion by changing my ReadWriteLock statement to > > >>>>> > > >>>>>ReadWriteLock fileLock = new > ReadWriteLock("c:/logRec.txt",loggerFacade); > > >>>>> > > >>>>>However, I received the same results as when I used new File(..). > > >>>>> > > >>>>>LeRoy > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> Oliver Zeigermann > > >>>>> > >>>>> n@gmail.com> > To > > >>>>> Jakarta Commons Users List > > >>>>> 07/06/2005 01:44 > > > >>>>> AM > cc > > >>>>> > > >>>>> > Subject > > >>>>> Please respond to Re: Transaction API, > ReadWriteLock > > >>>>> "Jakarta Commons > > >>>>> Users List" > > >>>>> > >>>>> arta.apache.org> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>>Most likely your problem ist that new File(..) creates different > > >>>>>objects in each thread. I would try using something like the path to > > >>>>>the file as String. > > >>>>> > > >>>>>Oliver > > >>>>> > > >>>>>On 7/5/05, LeRoy.Yanta@securian.com > wrote: > > >>>>> > > >>>>> > > >>>>>> > > >>>>>> > > >>>>>>I'm trying to use the ReadWriteLock class to acquire a write lock > on a > > >>>>> > > >>>>>file > > >>>>> > > >>>>> > > >>>>>>in a servlet. When I generate multiple threads of the servlet > using a > > >>>>> > > >>>>>WTE > > >>>>> > > >>>>> > > >>>>>>5.1 server in the WSAD 5.1 IDE, I'm not able to get ReadWriteLock > to > > >>>>> > > >>>>>block > > >>>>> > > >>>>> > > >>>>>>other servlet threads after the first servlet thread obtains the > lock. > > >>>>> > > >>>>>I'm > > >>>>> > > >>>>> > > >>>>>>using two IE browser windows to generate the two servlet threads. > Below > > >>>>> > > >>>>>is > > >>>>> > > >>>>> > > >>>>>>ReadWriteLock code I have in the servlet followed by the > > >>>>> > > >>>>>System.out.println > > >>>>> > > >>>>> > > >>>>>>statements that are generated in the server log file during my > test. > > >>>>>> > > >>>>>>ReadWriteLock fileLock = new ReadWriteLock(new File(c:/logRec.txt, > > >>>>>>loggerFacade); > > >>>>>>try { > > >>>>>> System.out.println("before acquiring a lock " + > > >>>>>>Thread.currentThread()); > > >>>>>> boolean result = > > >>>>>>fileLock.acquireWrite(Thread.currentThread(),Long.MAX_VALUE); > > >>>>>> System.out.println("lock result: " + result + " " + > > >>>>>>Thread.currentThread()); > > >>>>>> Thread.sleep(20000); > > >>>>>> System.out.println("after sleeping " + > Thread.currentThread()); > > >>>>>> FileWriter recFile = new FileWriter(c:/logRec.txt, true); > > >>>>>> recFile.write("text from testFileTran"); > > >>>>>> recFile.close(); > > >>>>>>} catch (InterruptedException e) { > > >>>>>> e.printStackTrace(System.err); > > >>>>>> > > >>>>>>} catch (IOException e) { > > >>>>>> e.printStackTrace(System.err); > > >>>>>> > > >>>>>>} finally { > > >>>>>> fileLock.release(Thread.currentThread()); > > >>>>>>} > > >>>>>> > > >>>>>>[7/5/05 8:26:03:326 CDT] 7c1477e SystemOut O before acquiring > a lock > > >>>>>>Thread[Servlet.Engine.Transports : 0,5,main] > > >>>>>>[7/5/05 8:26:03:326 CDT] 7c1477e SystemOut O lock result: true > > >>>>>>Thread[Servlet.Engine.Transports : 0,5,main] > > >>>>>>[7/5/05 8:26:08:384 CDT] 24c3477d SystemOut O before acquiring > a lock > > >>>>>>Thread[Servlet.Engine.Transports : 1,5,main] > > >>>>>>[7/5/05 8:26:08:384 CDT] 24c3477d SystemOut O lock result: true > > >>>>>>Thread[Servlet.Engine.Transports : 1,5,main] > > >>>>>>[7/5/05 8:26:23:335 CDT] 7c1477e SystemOut O after sleeping > > >>>>>>Thread[Servlet.Engine.Transports : 0,5,main] > > >>>>>>[7/5/05 8:26:28:382 CDT] 24c3477d SystemOut O after sleeping > > >>>>>>Thread[Servlet.Engine.Transports : 1,5,main] > > >>>>>> > > >>>>>> > > >>>>> > > >>>>>>From reviewing the Transaction documentation and mailing list > archives, > > >>>>> > > >>>>>I'm > > >>>>> > > >>>>> > > >>>>>>not able to determine what I'm doing wrong. > > >>>>>> > > >>>>>> > > > >>>>>>--------------------------------------------------------------------- > > >>>>>>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org > > >>>>>>For additional commands, e-mail: > commons-user-help@jakarta.apache.org > > >>>>>> > > >>>>>> > > >>>>> > > > >>>>>--------------------------------------------------------------------- > > >>>>>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org > > >>>>>For additional commands, e-mail: > commons-user-help@jakarta.apache.org > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > > >>>>>--------------------------------------------------------------------- > > >>>>>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org > > >>>>>For additional commands, e-mail: > commons-user-help@jakarta.apache.org > > >>>>> > > >>>>> > > >>>> > > >>>> > > >>>>--------------------------------------------------------------------- > > >>>>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org > > >>>>For additional commands, e-mail: commons-user-help@jakarta.apache.org > > >>>> > > >>> > > >>>--------------------------------------------------------------------- > > >>>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org > > >>>For additional commands, e-mail: commons-user-help@jakarta.apache.org > > >>> > > >>> > > >> > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org > > > For additional commands, e-mail: commons-user-help@jakarta.apache.org > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org > > For additional commands, e-mail: commons-user-help@jakarta.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org > For additional commands, e-mail: commons-user-help@jakarta.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org > For additional commands, e-mail: commons-user-help@jakarta.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-user-help@jakarta.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-user-help@jakarta.apache.org