aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes What's the purpose running of delete1 and update1 multiple times (DataClassTest) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "What Watch "What New topic
Author

What's the purpose running of delete1 and update1 multiple times (DataClassTest)

Ixus See
Ranch Hand

Joined: Jul 17, 2011
Posts: 160
can someone explain to me the purpose running delete1 and update1 multiple times ,since both of them will throw RNFE at lock() before entering delete1 and update function

I don't see the purpose of this...
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 4910
    
  10

It's a test harness and it's purpose is to test the locking mechanism of your Data class and that could be easily done with just 1 iteration. It's all about the update1 and delete1 thread to compete for the lock on record 1. So you certainly have to test that situation. But it even could be that the test runs to completion but still have an issue with your Data class, because the threads ran in a given order and the problem in your code only manifests itself when these threads run in some other order.
So indeed executing 100 times delete1 and update1 is pretty useless, therefor I suggested to add a random delete thread (like the update random thread), but this don't give you the guarantee that 2 threads will compete for the same record (a guarantee which you have with delete1 and update1 threads) and like I already indicated that's a situation you certainly want to test, because that's likely the cause of any issues (of threads not running to completion).
You could also re-use record numbers of deleted entries and then it makes more sense, because the create thread will create a record at position 1 (if the delete1 thread deleted this record already) or at the end of the map (otherwise), so the RNFE will not be thrown that frequently. And I don't know if my good buddy Roberto re-used record numbers of deleted entries, but he shared his test case with the community and you are free to adjust and make changes to this test to make it fit your needs. I re-used record numbers of deleted entries, so I had a whole bunch of thread pairs competing with each other to get a lock on the same record and that helped me to discover an issue in my locking mechanism. If you decided not to re-use these record numbers (it's not a must requirement) you could maybe adjust the code to have a delete and update thread which try to gain the lock of the same record, but not always record 1.

Hope it makes things a bit more clear.


SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
http://www.javaroe.be/
Ixus See
Ranch Hand

Joined: Jul 17, 2011
Posts: 160
I can run random update, delete any amount of times safely, I only have problem when i use the original code .. update 1 and delete1, basically it just keep throwing the same old exception.

Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 4910
    
  10

The code used in the test harness is how you are supposed to delete and/or update a record. So it's a 3 step process: lock, update (or delete), unlock. What happens when you just execute this little program (after adjusting it to fit the interface you've got).

Ixus See
Ranch Hand

Joined: Jul 17, 2011
Posts: 160
update thread produce this

suncertify.db.RecordNotFoundException
at suncertify.db.Data.lock(Data.java:163)
at Test.IxusTest$2.run(IxusTest.java:45)


----------------------------------------------------------

if you reuse a record that means your unique key creator will loop the entire cache for a null and return it as a unique key?

sounds very costly if you ask me.....

Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 4910
    
  10

And the most important thing: did your program end normally? I guess it did and the output is what you would expect.

Unfortunately this not means that your code is working as expected. Because the delete-thread will be already finished when the update-thread starts, so although you have . Therefore you need to tweak the program a bit: with adding a few Thread.sleep(100); calls you can change the execution of the threads (simulating the thread scheduler).



Can you explain what the adjustments in the program will do? And what's the output of this test run?
Ixus See
Ranch Hand

Joined: Jul 17, 2011
Posts: 160
suncertify.db.RecordNotFoundException
at suncertify.db.Data.lock(Data.java:163)
at Test.IxusTest$2.run(IxusTest.java:47)


I still get this out come... you are trying to simulate a wait.. that won't happen in this case too because of RNFE...

i did test if the lock is working by putting a println when it waits and after it wake up using updates only.. and both lines are printed... so I can safely assume it is working if i implemented it completely

so am I getting smarter each day, teacher? ;)
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 4910
    
  10

Ixus See wrote:I still get this out come... you are trying to simulate a wait.. that won't happen in this case too because of RNFE...

That's indeed the output you want to see. And indeed I'm simulating a wait (both threads want to lock same record, so one of them will go into waiting state). So it's not true that it won't happen because of RNFE. In the scenario I provided the update thread has to wait until the delete thread has finished (or if the update thread was the 1st one to execute, the delete thread has to wait until the delete thread has finished).
If this behavior is not the one you can verify in your implementation, you'll almost certain to fail because you are violating the instructions of the lock-method in the given interface.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: What's the purpose running of delete1 and update1 multiple times (DataClassTest)
 
Similar Threads
Continuing a transaction after deadlock
Compile errors when assigning Final variable
Test Your Effective Locking Mechanism by Threads
Attempted to deploy PersistenceUnit _ for which predeploy method either had not calle
OutOfMemoryError while running DataClassTest