Yes, all participating threads would need to access the same transaction manager.
Oliver On 7/6/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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 > <oliver.zeigerman > [EMAIL PROTECTED]> > To > Jakarta Commons Users List > 07/06/2005 09:47 <commons-user@jakarta.apache.org> > AM cc > > Subject > Please respond to Re: Transaction API, ReadWriteLock > "Jakarta Commons > Users List" > <[EMAIL PROTECTED] > arta.apache.org> > > > > > > > Exactly. In most cases I would recommend to use a manager. > > Oliver > > On 7/6/05, Aaron Hamid <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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 > > >>>>> <oliver.zeigerman > > >>>>> [EMAIL PROTECTED]> > To > > >>>>> Jakarta Commons Users List > > >>>>> 07/06/2005 01:44 > <commons-user@jakarta.apache.org> > > >>>>> AM > cc > > >>>>> > > >>>>> > Subject > > >>>>> Please respond to Re: Transaction API, > ReadWriteLock > > >>>>> "Jakarta Commons > > >>>>> Users List" > > >>>>> <[EMAIL PROTECTED] > > >>>>> 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, [EMAIL PROTECTED] <[EMAIL PROTECTED]> > 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: [EMAIL PROTECTED] > > >>>>>>For additional commands, e-mail: > [EMAIL PROTECTED] > > >>>>>> > > >>>>>> > > >>>>> > > > >>>>>--------------------------------------------------------------------- > > >>>>>To unsubscribe, e-mail: [EMAIL PROTECTED] > > >>>>>For additional commands, e-mail: > [EMAIL PROTECTED] > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > > >>>>>--------------------------------------------------------------------- > > >>>>>To unsubscribe, e-mail: [EMAIL PROTECTED] > > >>>>>For additional commands, e-mail: > [EMAIL PROTECTED] > > >>>>> > > >>>>> > > >>>> > > >>>> > > >>>>--------------------------------------------------------------------- > > >>>>To unsubscribe, e-mail: [EMAIL PROTECTED] > > >>>>For additional commands, e-mail: [EMAIL PROTECTED] > > >>>> > > >>> > > >>>--------------------------------------------------------------------- > > >>>To unsubscribe, e-mail: [EMAIL PROTECTED] > > >>>For additional commands, e-mail: [EMAIL PROTECTED] > > >>> > > >>> > > >> > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]