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 To Jakarta Commons Users List 07/06/2005 09:47 AM cc Subject Please respond to Re: Transaction API, ReadWriteLock "Jakarta Commons Users List" 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