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 - RESOLVED
Date Thu, 07 Jul 2005 11:42:34 GMT





Oliver,

Thanks for your help on this issue.

LeRoy





                                                                           
             Oliver Zeigermann                                             
             <oliver.zeigerman                                             
             n@gmail.com>                                               To 
                                       Jakarta Commons Users List          
             07/07/2005 02: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>                                              
                                                                           
                                                                           




Yes, all participating threads would need to access the same
transaction manager.

Oliver

On 7/6/05, LeRoy.Yanta@securian.com <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
>              <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
>
>

---------------------------------------------------------------------
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