aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Take this Testing Tool for Data Class Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Take this Testing Tool for Data Class" Watch "Take this Testing Tool for Data Class" New topic
Author

Take this Testing Tool for Data Class

Sam Codean
Ranch Hand

Joined: Feb 26, 2006
Posts: 194
Hi All,
I have seen a lot of posts related to Testing the Threading issues of Data Class.
I thought it was best to write a small testing tool that will spawn new threads and shoot transactions. Log the actions and using those logs we can see if it is indeed performing well.

I gave it an initial shot and am pasting the code. Please could someone review this and update it if necessary? It would be good to have this in the forum so that everyone has access to it provided i am not violating any rules, Moderators please ack.

[ November 10, 2006: Message edited by: Sam Codean ]

-Sam Codean<br />SCJP 1.4 (98%)<br />SCJD 5.0 (87.5%)
Tim Anlauf
Greenhorn

Joined: Oct 11, 2006
Posts: 22
I tried your code. Only checking if it runs.
I found 1 problem in your code in method doUpdate() :

record[record.length] = "1"; must be
record[record.length-1] = "1";
Sam Codean
Ranch Hand

Joined: Feb 26, 2006
Posts: 194
Hey good catch. Actually i found out that too but forgot to update this post
Tim Anlauf
Greenhorn

Joined: Oct 11, 2006
Posts: 22
I found a secord little bug. the start method isn't invoked.

So far I played a bit around with your test class and found out that my Data class isn't thread safe.

I thought it is and want to write a test by myself.
You piece of code is good starting point thanks.
Tim Anlauf
Greenhorn

Joined: Oct 11, 2006
Posts: 22
Now I found the "bug". For update/delete/create method my application is thread safe.

But my read and find methods aren't not.

Example :

if 1 thread is writing into db file and onther thread is reading --> the file pointer is "missplaced" and the write happens in the wrong place.

I don't want to syncronize the read methods, because only 1 user could read at a certain time !

Has somebody a solution ?

Tim
Mike Ngo
Ranch Hand

Joined: Oct 16, 2006
Posts: 89
I don't want to syncronize the read methods, because only 1 user could read at a certain time !


How do you know only one thread can read at a time? Actually, you can guarantee that read/update operations happen sequentually because they require a lock. With a read operation, you can't ! because there is no lock.

Those CRUD operations on a file must be atomic meaning they must be synchronized.
Sam Codean
Ranch Hand

Joined: Feb 26, 2006
Posts: 194
Mike is right. At a time we can use only one of the CRUD methods so that the file is not corrupted as you are facing. I think there are two levels of locking in the project
1. Locking the file for any CRUD update (through syncronisation)
This prevents corruption of data through random read write (R/W itself is incorrect)
2. Locking a record for updation deletion
This helps in dirty reads and Phantom Records (R/W is correct but a sequence of R/W is wrong)
Kalle Tjarnlund
Greenhorn

Joined: Aug 20, 2006
Posts: 10
I think this class was very usefull. There's one thing regarding my own implementation that does not work very well with this solution. I use my implementation class of the Data class as a part of the locking strategy.

In my DB interface it is stated, for the lock method, "Locks a record so that it can only be updated or deleted by this client". Therefore one client has its own instance of the Data class thus a record can only be updated or delted by the Data instance that aquired the lock.

In the test class there is only one Data instance but with multiple threads which implies a solution where all clients share the same Data instance.

Is it only me or does anyone els have a one client = one Data class instance?
Maybe I have missinterpreted the requirements?

Best Regards,
Kalle


SCJP 1.5<br />SCJD URLyBird (in progress)
Sam Codean
Ranch Hand

Joined: Feb 26, 2006
Posts: 194
It depends on the mode too. If it is the Standalone mode then i will have one data instance per client. If it is the network server mode then there is only one data instance which is hosted on the RMI server and that will be used by all the clients.

Hope that helps!!
Mark Smyth
Ranch Hand

Joined: Feb 04, 2004
Posts: 288
Originally posted by Kalle Tjarnlund:
I think this class was very usefull. There's one thing regarding my own implementation that does not work very well with this solution. I use my implementation class of the Data class as a part of the locking strategy.

In my DB interface it is stated, for the lock method, "Locks a record so that it can only be updated or deleted by this client". Therefore one client has its own instance of the Data class thus a record can only be updated or delted by the Data instance that aquired the lock.

In the test class there is only one Data instance but with multiple threads which implies a solution where all clients share the same Data instance.

Is it only me or does anyone els have a one client = one Data class instance?
Maybe I have missinterpreted the requirements?

Best Regards,
Kalle


"Locks a record so that it can only be updated or deleted by this client". I would take that sentence to mean the client that has called the lock method on this data object, and it doesn't in any way suggest that each client should have its own data object.

How do you ensure that two clients using different data objects are not editing the same record at the same time? Also when in network node does this mean that each client has its own server? That does not seem like a good design to me.

I think that at the data class needs to be able to support multiple threads of execution using the locking methods that the interface specified. I don't wish to be harsh but if the data class is not cannot support multiple threads of execution then you could be looking at signifigant locking deductions or an automatic failure, and it would be a shame after putting inso much effort into the SCJD.

Perhaps you could describe your locking process in more detail, so I could get a clearer picture in my head of how it all works?


SCJP<br />SCJD
Kalle Tjarnlund
Greenhorn

Joined: Aug 20, 2006
Posts: 10
Originally posted by Mark Smyth:


"Locks a record so that it can only be updated or deleted by this client". I would take that sentence to mean the client that has called the lock method on this data object, and it doesn't in any way suggest that each client should have its own data object.

How do you ensure that two clients using different data objects are not editing the same record at the same time? Also when in network node does this mean that each client has its own server? That does not seem like a good design to me.

I think that at the data class needs to be able to support multiple threads of execution using the locking methods that the interface specified. I don't wish to be harsh but if the data class is not cannot support multiple threads of execution then you could be looking at signifigant locking deductions or an automatic failure, and it would be a shame after putting inso much effort into the SCJD.

Perhaps you could describe your locking process in more detail, so I could get a clearer picture in my head of how it all works?


Jupps, automatic failure is one thing we all really wanna avoid. I'll look over the locking. In the current solution I share a lock manager between the data objects so it's no problem of assuring that clients does not update the same record. In the network mode I utilize the RMI Factory pattern so that each client has it's own business object (yes my client is thin) and thus each client has its own underlying data object (which shares the same lock manager).

Maybe i misunderstod/overinpreted (is that an english word?) the instruction (and specially the meaning of "this client) a bit but how can one assure that it is the same client using the cookie if there are not multiple data objects. What I mean is that if I would only have one data object then a badly written client could use a faulty cookie and update a record that another client has locked. Well, putting this in writing gets me feeling I'm way off, but there was actually some kind of logical thought behind my impl. ;-).

I'm greatfull for the feedback and actually my implementation becomes a bit less complex removing the check that it only the data object that locked a row that actually can change and release it.

BTW, when we are one the Data class topic. I could'nt see that there was anything stated about how the data class is instanciated so I guess there is no rule about having the contructor as the testing tool implies?

Best Regards,
Kalle
[ November 21, 2006: Message edited by: Kalle Tjarnlund ]
Mark Smyth
Ranch Hand

Joined: Feb 04, 2004
Posts: 288
Originally posted by Kalle Tjarnlund:


Jupps, automatic failure is one thing we all really wanna avoid. I'll look over the locking. In the current solution I share a lock manager between the data objects so it's no problem of assuring that clients does not update the same record. In the network mode I utilize the RMI Factory pattern so that each client has it's own business object (yes my client is thin) and thus each client has its own underlying data object (which shares the same lock manager).

Maybe i misunderstod/overinpreted (is that an english word?) the instruction (and specially the meaning of "this client) a bit but how can one assure that it is the same client using the cookie if there are not multiple data objects. What I mean is that if I would only have one data object then a badly written client could use a faulty cookie and update a record that another client has locked. Well, putting this in writing gets me feeling I'm way off, but there was actually some kind of logical thought behind my impl. ;-).

I'm greatfull for the feedback and actually my implementation becomes a bit less complex removing the check that it only the data object that locked a row that actually can change and release it.

BTW, when we are one the Data class topic. I could'nt see that there was anything stated about how the data class is instanciated so I guess there is no rule about having the contructor as the testing tool implies?

Best Regards,
Kalle

[ November 21, 2006: Message edited by: Kalle Tjarnlund ]


Hi kalle,

It sounds like you have a devised a good working solution for your locking problem. And in theory if you have written down and justified your design decisions that should be an acceptable. My only concern would be (And I have no idea how the assignment is marked) is that the assignment evaluator may have a test harness program that automatically tests the data class ( much like the one that sam wrote). If this was the case then I think your solution would be vunerable.

My solution is also a thin client which uses a remote server object that just has a book and search method. All my remote clients have a reference to this same server object which has a reference to a single data instance.

Locking is based on the thread reference stored in a Hashmap<Integer, Thread> with the recNo as the key(I have no means for passing cookies back to the client with my DBMain interface) therefore my lock / update / unlock sequence must happen within a single RMI call on the book method.

Like I said your solutions sounds a perfectly fine to me and I can understand why you would be reluctant to change it if it is working well for you. But I would just bear in mind that the examiners may be expecting a data class capable of handling multiple threads.

Regards,
Mark
Kalle Tjarnlund
Greenhorn

Joined: Aug 20, 2006
Posts: 10
Originally posted by Mark Smyth:


Hi kalle,

It sounds like you have a devised a good working solution for your locking problem. And in theory if you have written down and justified your design decisions that should be an acceptable. My only concern would be (And I have no idea how the assignment is marked) is that the assignment evaluator may have a test harness program that automatically tests the data class ( much like the one that sam wrote). If this was the case then I think your solution would be vunerable.

My solution is also a thin client which uses a remote server object that just has a book and search method. All my remote clients have a reference to this same server object which has a reference to a single data instance.

Locking is based on the thread reference stored in a Hashmap<Integer, Thread> with the recNo as the key(I have no means for passing cookies back to the client with my DBMain interface) therefore my lock / update / unlock sequence must happen within a single RMI call on the book method.

Like I said your solutions sounds a perfectly fine to me and I can understand why you would be reluctant to change it if it is working well for you. But I would just bear in mind that the examiners may be expecting a data class capable of handling multiple threads.

Regards,
Mark


Hi!
Thanks for the input. It actually seems that we have solutions that are quite alike actually but you utilize the Thread and I have used the Data object but I think that your thread solution is a safer solution since, as you point out, there is a risk that the automatic testing uses one Data object which is shared amoungst threads which could result in point deduction, or worse case automatic failure with my solution. I'm gonna take your advice and redesign the solution a bit.

Regarding the "thin client" approach I don't really understand why you need to have a reference to the thread in your solution when you lock a record since the lock/update/unlock will execute in one call (I have the exact same solution). Is it just to assure that no other thread than the one that locked the record is trying to use a "false" cookie. In other words have you cinda interpreted "this client" == "this thread"?
If you were to interpret "this client" to "the client with the correct cookie value" then you would not need to check the thread?


BR,
Kalle
Mark Smyth
Ranch Hand

Joined: Feb 04, 2004
Posts: 288
Originally posted by Kalle Tjarnlund:


Hi!

Regarding the "thin client" approach I don't really understand why you need to have a reference to the thread in your solution when you lock a record since the lock/update/unlock will execute in one call (I have the exact same solution). Is it just to assure that no other thread than the one that locked the record is trying to use a "false" cookie. In other words have you cinda interpreted "this client" == "this thread"?
If you were to interpret "this client" to "the client with the correct cookie value" then you would not need to check the thread?


BR,
Kalle



In other words have you cinda interpreted "this client" == "this thread"?


Yes it is just to ensure that a different thread cannot unlock a record that it has not locked. This solution would not work if the lock and unlock methods were called using seperate RMI calls and it would not be guaranteed that the same thread would be used to execute the lock and unlock methods.


If you were to interpret "this client" to "the client with the correct cookie value" then you would not need to check the thread?


Correct. The lock method in my DMain interfce are:



So I do not have the option of returning a cookie to the client so it can later identify itself to the unlock method. But I know that other versions of the SCJD have lock methods similar to the following, which allow for a much better solution to the problem.



So if your api is like this then you should use the cookie generated to identify the client rather than the thread reference as this is a much cleaner and better approach.

Regards,
Mark
Kalle Tjarnlund
Greenhorn

Joined: Aug 20, 2006
Posts: 10
Hi!
Thanks for the answer, now i finally got it ;-).
And thanks to Sam for a good test util, was very handy when i did a refactor on my Data and lockmanager class.

Regards,
Kalle
Ken Boyd
Ranch Hand

Joined: Dec 10, 2003
Posts: 329
Originally posted by Sam Codean:
Hi All,
I have seen a lot of posts related to Testing the Threading issues of Data Class.
I thought it was best to write a small testing tool that will spawn new threads and shoot transactions. Log the actions and using those logs we can see if it is indeed performing well.

I gave it an initial shot and am pasting the code. Please could someone review this and update it if necessary? It would be good to have this in the forum so that everyone has access to it provided i am not violating any rules, Moderators please ack.


[ November 10, 2006: Message edited by: Sam Codean ]



Sam,
First of all thanks for posting excellent testing code. After digging many threads I found yours and have couple of questions. Also posted new threads but no reply so trying to get some feedback from you.

If I update doUpdate() method with two update with different cookie will that be deadlock?

I have URLyBird assignment with cookies so same signature for lock/unlock.

Now if we have two update request on same index number e.g. 10 in doUpdate() method that means one client trying to update i.e. book two records at the same time. I have mention in my choice.txt that it is not allowed since UI has single row selection feature via JTable.

Can you please comment on this. It will be of great help.

Thanks,
Ken
[ May 11, 2007: Message edited by: Ken Boyd ]

SCJP, SCWCD, SCBCD, SCJD, BB Java2 and JSP1.1
Lucy Hummel
Ranch Hand

Joined: Apr 07, 2005
Posts: 232
Hi,

As far I as I can see Sam's code, the method
  • doUpdate()
  • should have a finally block in that the unlock happens.


    ----------------------------------<br />| SCJP, SCWCD, SCBCD, SCEA, SCJD |<br />----------------------------------
    Pablo Aravena
    Greenhorn

    Joined: May 04, 2006
    Posts: 13
    Hi friends

    When I saw the test code something came to my mind. It's possible that my Data class will failed the automatic test, because I haven't included the lock and unlock method calls inside the update or delete methods. Instead of that I have created an adapter class where I handle the locking and unlocking of record as follow:

    <pre>
    long cookie = data.lock(recNo)
    try {
    data.delete(recNo, cookie);
    } finally {
    data.unlock(recNo,cookie);
    }
    </pre>

    Reading my assignment instruction again I ran into with this sentence:

    <b>Portions of your submission will be analyzed
    by software; where a specific spelling or structure is required, even a
    slight deviation could result in automatic failure</b>

    This means that only in my Data class I have to include all the code required to pass this automatic test.

    What do you think about this issue?

    Thanks in advance
    Mark Smyth
    Ranch Hand

    Joined: Feb 04, 2004
    Posts: 288
    Originally posted by Pablo Aravena:
    Hi friends

    When I saw the test code something came to my mind. It's possible that my Data class will failed the automatic test, because I haven't included the lock and unlock method calls inside the update or delete methods. Instead of that I have created an adapter class where I handle the locking and unlocking of record as follow:

    <pre>
    long cookie = data.lock(recNo)
    try {
    data.delete(recNo, cookie);
    } finally {
    data.unlock(recNo,cookie);
    }
    </pre>

    Reading my assignment instruction again I ran into with this sentence:

    <b>Portions of your submission will be analyzed
    by software; where a specific spelling or structure is required, even a
    slight deviation could result in automatic failure</b>

    This means that only in my Data class I have to include all the code required to pass this automatic test.

    What do you think about this issue?

    Thanks in advance


    Not to worry you code is just fine. The code posted above is a TestData class not the actual data class itself. If you look more closely at the doUpdate method for example it calls data lock -> update -> unlock in the same way as your Adapter does. So Sams data update methods do not call lock unlock internally either.

    Regards,
    Mark
    Ken Boyd
    Ranch Hand

    Joined: Dec 10, 2003
    Posts: 329
    Mark is right. My data class update and delete methods doesn't include lock and unlock. In fact it shouldn't be in that place because before calling update and delete you have to check whether lock is available or not.
    Pablo Aravena
    Greenhorn

    Joined: May 04, 2006
    Posts: 13
    Thanks a lot friends now I feel better with my design
    Mihai Radulescu
    Ranch Hand

    Joined: Sep 18, 2003
    Posts: 916

    Hi, guys

    I'll like to add my two cents here, the test proposals are good but they don't test provides an essential test for the multithread - the deathly deathlock.

    What you guys think about it ?


    Regards,
    M


    SCJP, SCJD, SCWCD, OCPJBCD
    Ken Boyd
    Ranch Hand

    Joined: Dec 10, 2003
    Posts: 329
    If you notice my first reply with modified test code (shown by ==> sign) I see deadlock in my code when I run the test. But again it was poor way to break the Data class locking.

    As per comment from other ranchers who pass says if you run test on record where 50 threads try to book 1000 times you should see modified field value to be 50,000 or you can have random number of record index 0 to 30 at the end of test one of the modified (meaning you increment one field with count) record will show 50,000 value.

    But you try to create deadlock by allowing user to book multiple records at same time then you will have multiple problems.

    e.g. user A selected 4 records to book. Now user B selects 5 records to book but out of that 5 records 4 records are locked by user A. Also to add user C in the mix with more possibility of booking records which are locked by user A or B. Now you are in deep trouble with critical decision to make who will get what??? I think it is out scope of the assignment since I have document that only 1 record can be book vis GUI and for multiple records run loop that many times to book records.

    it will be nice if you can reply to following thread where I describe possible deadlock scenario.

    Thanks
    Ken
    Mihai Radulescu
    Ranch Hand

    Joined: Sep 18, 2003
    Posts: 916

    Hi Ken (&Co)

    It is true you can spot a death lock with this code, but unfortunately you can not use it for an automate test. More precisely you can not be shore that all your client threads are done - end them task without any possible problem.
    So if want to check if your test succeed you must consult the log file, but you don't have "strait" result (like "test succeed" or "test fails") - you must deduce this.
    By example in some of my test I let 300 clients(threads) to operate 30 record, each clients operate every record for 300 times - I have a strong test machine - the test takes some hours and the log files are enormous.

    To ensure that all of my clients (threads) are done at the end of the test, I build a counter (I can post it to you the source if you are interested). After a client(thread) ends its task (form a reason or other) it hits this counter. The counter knows how many hits must expect(the count clients), when it has all the hits - all the clients are done with them tasks - it notifies a successful test.

    From time to time I interrupt some of my threads just to be shore that this action does not influence the lock work flow.

    Regards,
    M
    Ken Boyd
    Ranch Hand

    Joined: Dec 10, 2003
    Posts: 329
    Originally posted by Mihai Radulescu:
    Hi Ken (&Co)

    It is true you can spot a death lock with this code, but unfortunately you can not use it for an automate test. More precisely you can not be shore that all your client threads are done - end them task without any possible problem.
    So if want to check if your test succeed you must consult the log file, but you don't have "strait" result (like "test succeed" or "test fails") - you must deduce this.
    By example in some of my test I let 300 clients(threads) to operate 30 record, each clients operate every record for 300 times - I have a strong test machine - the test takes some hours and the log files are enormous.

    To ensure that all of my clients (threads) are done at the end of the test, I build a counter (I can post it to you the source if you are interested). After a client(thread) ends its task (form a reason or other) it hits this counter. The counter knows how many hits must expect(the count clients), when it has all the hits - all the clients are done with them tasks - it notifies a successful test.

    From time to time I interrupt some of my threads just to be shore that this action does not influence the lock work flow.

    Regards,
    M


    Hi Mihai,
    Yes I am interested in your test code. Please post it asap. I am very much interested in testing Data class to the limit. You always want to test more and more till end. I am also putting print statement where hashmap content is displayed so you can see that at no time same record is locked by two different cookies i.e. clients.

    Thanks,
    Ken
    Mihai Radulescu
    Ranch Hand

    Joined: Sep 18, 2003
    Posts: 916

    Hi Ken,

    What you mean by "asap" ?
    Ken Boyd
    Ranch Hand

    Joined: Dec 10, 2003
    Posts: 329
    Originally posted by Mihai Radulescu:
    Hi Ken,

    What you mean by "asap" ?


    Hi Mihai,
    Oh I mean if you can post your test code (that's what I thought from previous post) as early as possible so I can try out against my Data class. Since I have done many test against Data class of my own I would like to try someone else test to verify locking is good.
    I mean many ranchers don't like to post their test code but Andrew posted in many threads that it is okay to post test code. It will nice if you can post it.

    Thanks,
    Ken
    Mihai Radulescu
    Ranch Hand

    Joined: Sep 18, 2003
    Posts: 916

    Oh, my mistake, I thought that your "asap" is some sort of transport protocol.

    here we go : the next class in the Counter, its purpose is to check if all the threads are done.


    this can be used together with some other tests, test which are similar with the upper one - the only difference is that when a thread leave its run method is hits the Counter - all threads must use th some Counter instance.
    An other trick : spawn your client threads in two steeps - create and store them in to a list an then use the list to start them - after this go once more over this list and call the interrupt method. If at the end of the test you still can see the "Test succeed." message - no death lock other wise .... (start to panic, run around in circles, make strange signs with your hands, you know the usual).

    To be shore you must do the tests :
    1. with your lock manager alone.
    2. with your data class.
    3. with your clients.

    I hope this helps.

    Regards,
    M
    Ken Boyd
    Ranch Hand

    Joined: Dec 10, 2003
    Posts: 329
    Thanks Mihai for test code I will post results soon.
    Prash Gali
    Greenhorn

    Joined: Dec 20, 2005
    Posts: 22
    Hi Mihai and Ken,
    I would apprecaite if one of you can show me an example code on how to use Mihai's class


    SCEA 5.0 SCJD SCBCD
    Mihai Radulescu
    Ranch Hand

    Joined: Sep 18, 2003
    Posts: 916

    Hi Prash,

    You must define a thread target (a class which implements Runnable) similar with the one from the beginning of the post.


    To make the things more interesting try to iterate over the Thread list and to interrupt them. Make a test without interrupt and one with interrupt - both must succeed.

    Regards,
    M
    [ June 01, 2007: Message edited by: Barry Gaunt ]
    Prash Gali
    Greenhorn

    Joined: Dec 20, 2005
    Posts: 22
    When running the test code posted by sam, i am seeing this issue.

    1) Thread 1 deletes a record and Thread 2 tries to read the deleted record. I receive RecordNotFound.
    2) Thread 2 deletes a record and Thread 3 tries to update the record, RecordNotFound exception is thrown.

    The bottom line is since multiple threads are performing random method call, there can be a chance that the same record number can be used by one thread to delete the record and other thread to access the same deleted record.
    So, is this test really testing concurrency? If situation like this happens, can i not worry about it?
    Mihai Radulescu
    Ranch Hand

    Joined: Sep 18, 2003
    Posts: 916

    Hi Prash

    Yes this test programs tests the concurrency but as I explain before, the test from Sam shows only the workflow, you must read this workflow information and to interpret it. With every new test run you'll get a new work flow. But you don't see if all your thread are really done or some are still some waiting (in a possible deathlock).

    Try to simulate a death lock and try to figure out (by using the output information) that a death lock situation occurs.
    What you see ?


    Regards
    M
    [ May 21, 2007: Message edited by: Mihai Radulescu ]
    Ken Boyd
    Ranch Hand

    Joined: Dec 10, 2003
    Posts: 329
    Originally posted by Prash Gali:
    When running the test code posted by sam, i am seeing this issue.

    1) Thread 1 deletes a record and Thread 2 tries to read the deleted record. I receive RecordNotFound.
    2) Thread 2 deletes a record and Thread 3 tries to update the record, RecordNotFound exception is thrown.

    The bottom line is since multiple threads are performing random method call, there can be a chance that the same record number can be used by one thread to delete the record and other thread to access the same deleted record.
    So, is this test really testing concurrency? If situation like this happens, can i not worry about it?



    Prash,
    Don't worry about Sam test code it's like starting point. I mean if one thread try to update record number 10 with cookie 100 and later on try to unlock with cookie 200 your program should reject it since it was locked using 100. Also method try to update record 20 with cookie 100 due to random.index used in update/delete method which is not right way to test it. Your program shouldn't allow update and delete of any record if matching cookie is not found as everybody has to get lock i.e. lockcookie to lock record for crud operation.

    Ken
    Ken Boyd
    Ranch Hand

    Joined: Dec 10, 2003
    Posts: 329
    Originally posted by Mihai Radulescu:
    Hi Prash

    Yes this test programs tests the concurrency but as I explain before, the test from Sam shows only the workflow, you must read this workflow information and to interpret it. With every new test run you'll get a new work flow. But you don't see if all your thread are really done or some are still some waiting (in a possible deathlock).

    Try to simulate a death lock and try to figure out (by using the output information) that a death lock situation occurs.
    What you see ?


    Regards
    M

    [ May 21, 2007: Message edited by: Mihai Radulescu ]


    Mihai,
    Thanks for your test code (good one). I have lockcookie in my URLyBrid assignment and tested your code with 20 100 30 and 50 100 30 combination and end result was "Test Succeed". Initially it was problem with RMI but after switching back to factory pattern I am getting succeed in both remote and local mode. I know you have submitted assignment and waiting for written exam but mean while if you have anything else to add to test code or found any new trick to attack data class please let me know.

    I have also done some more testing using Andrew test class (modified a lot) to perform more test in remote and local mode. At this point everything looks good. I might more towards finshing line.

    Thanks,
    Ken

    BTW: Did you implement crash client and deadlock recovery in your data class. I am not doing it since one client locks one record and client crash is out scope of this assignment. You can do it but why to implement when not specified anywhere in assignment and ask for reduction in score if wrong in implementing.
    [ May 31, 2007: Message edited by: Ken Boyd ]
    Lucy Hummel
    Ranch Hand

    Joined: Apr 07, 2005
    Posts: 232
    Hi Ken,

    Originally posted by Ken Boyd:

    BTW: Did you implement crash client and deadlock recovery in your data class. I am not doing it since one client locks one record and client crash is out scope of this assignment. You can do it but why to implement when not specified anywhere in assignment and ask for reduction in score if wrong in implementing.


    You gave already the reason for not supporting this issues.

    I did not supported the issues in my solution.
    Ken Boyd
    Ranch Hand

    Joined: Dec 10, 2003
    Posts: 329
    Originally posted by Hummel Lucy:
    Hi Ken,



    You gave already the reason for not supporting this issues.

    I did not supported the issues in my solution.


    Hi Hummel,
    Thanks for your reply. I think you have also submitted your assignment.

    Ken
    Lucy Hummel
    Ranch Hand

    Joined: Apr 07, 2005
    Posts: 232
    Hi Ken,

    Yes, I have uploaded my solution for two weeks but I do not have yet a result.

    So I do not can say for sure that you should not do the two requirements mentioned by you.

    In case their is no clear requirment to provide one of the two items, I would not implemented them.

    Good Luck
    Ken Boyd
    Ranch Hand

    Joined: Dec 10, 2003
    Posts: 329
    I mean they won't say anything remotely in requirement that implement deadlock prevention or crash client recovery. I mean two client shouldn't access one record at the same time is must for any program and shouldn't create deadlock unless tester try to tweak that with stupid test code I mention previously (in that case any program will crash)

    Anytime you follow lock-->update-->unlock or lock-->delete-->unlock sequence your program should work without any problems for 50k hits on single record for all operation or only UPDATE for one record with 50k hits (where result should be 50K number at updated row)
    Mihai Radulescu
    Ranch Hand

    Joined: Sep 18, 2003
    Posts: 916

    Hi people,
    It seams that this post still make waves, I just back after a week of holiday(one week without any form of computer) so let's get on.

    My lock manager does not have crash client detection, this will be over the lock manager resposibility. I do this in by using the Unreferenced interface - but I think that this point is not really necessary, I also think that will be enough only to mention it in your choices file.

    Dead lock prevention, this is done in the lock manager. There are a lot of possibilities and I choose the simplest of them. Let's consider the scenario

    1.client A locks record 1
    2.client B locks record 2
    3.client A locks record 2
    4.client B locks record 1

    a classical death lock situation. The simplest way to avoid it is to let the user to lock only one client once. If a client tries to lock more than one record once an exception occurs (and the lock is aborted). This solution brings some advantages and some disadvantages.


    Other interesting test to do :
    1.two clients client locks the same record and one record delete the record.
    2.try to simulate death lock scenarios (like in the example above)
    3.try to interrupt (by using the thread interrupt) any waiting process, and test if the process was really aborted. By example if the delete method must wait until the record becomes available, what happen if the delete thread is interrupted ?
    4.run the test with less client threads and a lot of records (3 clients and 100 records) and with a lot of clients and less records.

    Regards,
    M
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Take this Testing Tool for Data Class