commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From LeRoy.Ya...@securian.com
Subject Re: Transaction API, ReadWriteLock
Date Wed, 06 Jul 2005 18:36:18 GMT





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                                             
             n@gmail.com>                                               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"                                                
             <commons-user@jak                                             
             arta.apache.org>                                              
                                                                           
                                                                           




Exactly. In most cases I would recommend to use a manager.

Oliver

On 7/6/05, Aaron Hamid <arh14@cornell.edu> 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 <oliver.zeigermann@gmail.com> 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 <arh14@cornell.edu> 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 <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
> >>>>>            <oliver.zeigerman
> >>>>>            n@gmail.com>
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"
> >>>>>            <commons-user@jak
> >>>>>            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 <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


Mime
View raw message