• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

How can i test the lock situation?

 
Ranch Hand
Posts: 128
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dear fellows
I tried to test the deadlock situation.
I did domething like:
if(lock)
wait()
not
thread.sleep(timeout)
I testeing in the same machine with VAJ 4.0, with one server and two instance of the clients all executed from VAJ environment.
But looks like both clients waits for the timeout, the second one never go to wait() method.
I also implemented a Timer for the deadlock and I really don�t now how to test in the same machine.
Some advice ?
Thanks in advance
 
Ranch Hand
Posts: 133
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You must put the Thread.sleep(1000) outside
the synchronized block like this
synchronized (lockVector) {
wait()
}

Thread.sleep(1000)
Hope that helps
Enrico
 
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I used the command-line debugger (jdb) to test my locking scheme.
I ran two or three instances of the client app without the GUI -- as essentially my own test-harness. I ran each in the debugger. I set a breakpoint right after the lock()-call in each one.
That showed that when a given record was locked (by whichever client I'd started first), other clients indeed had to wait until I entered "continue" in the debugger in which the other one(s) was(were) running. That allowed the one(s) with the lock to release it, thereby giving the other(s) a chance to proceed -- realizing that there is contention sometimes (when more than one is waiting for the lock on a given record).
 
Ranch Hand
Posts: 273
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello:
One of the Rancher suggested me to disable the unlock method, recompile and run it. I saw blocked message, but it froze my screen.
Another suggestion was quite good. Implement a delay Thread.sleep(...) at the begining of your unlock method. Happy testing. -Bal
 
God is a comedian playing for an audience that is afraid to laugh - Voltair. tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic