-Sam Codean<br />SCJP 1.4 (98%)<br />SCJD 5.0 (87.5%)
-Sam Codean<br />SCJP 1.4 (98%)<br />SCJD 5.0 (87.5%)
I don't want to syncronize the read methods, because only 1 user could read at a certain time !
-Sam Codean<br />SCJP 1.4 (98%)<br />SCJD 5.0 (87.5%)
SCJP 1.5<br />SCJD URLyBird (in progress)
-Sam Codean<br />SCJP 1.4 (98%)<br />SCJD 5.0 (87.5%)
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
SCJP<br />SCJD
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?
SCJP 1.5<br />SCJD URLyBird (in progress)
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 ]
SCJP<br />SCJD
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
SCJP 1.5<br />SCJD URLyBird (in progress)
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"?
If you were to interpret "this client" to "the client with the correct cookie value" then you would not need to check the thread?
SCJP<br />SCJD
SCJP 1.5<br />SCJD URLyBird (in progress)
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 ]
SCJP, SCWCD, SCBCD, SCJD, BB Java2 and JSP1.1
----------------------------------<br />| SCJP, SCWCD, SCBCD, SCEA, SCJD |<br />----------------------------------
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
SCJP<br />SCJD
SCJP, SCWCD, SCBCD, SCJD, BB Java2 and JSP1.1
SCJP, SCJD, SCWCD, OCPJBCD
SCJP, SCWCD, SCBCD, SCJD, BB Java2 and JSP1.1
SCJP, SCJD, SCWCD, OCPJBCD
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
SCJP, SCWCD, SCBCD, SCJD, BB Java2 and JSP1.1
SCJP, SCJD, SCWCD, OCPJBCD
Originally posted by Mihai Radulescu:
Hi Ken,
What you mean by "asap" ?
SCJP, SCWCD, SCBCD, SCJD, BB Java2 and JSP1.1
SCJP, SCJD, SCWCD, OCPJBCD
SCJP, SCWCD, SCBCD, SCJD, BB Java2 and JSP1.1
SCEA 5.0 SCJD SCBCD
SCJP, SCJD, SCWCD, OCPJBCD
SCEA 5.0 SCJD SCBCD
SCJP, SCJD, SCWCD, OCPJBCD
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?
SCJP, SCWCD, SCBCD, SCJD, BB Java2 and JSP1.1
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 ]
SCJP, SCWCD, SCBCD, SCJD, BB Java2 and JSP1.1
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.
----------------------------------<br />| SCJP, SCWCD, SCBCD, SCEA, SCJD |<br />----------------------------------
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.
SCJP, SCWCD, SCBCD, SCJD, BB Java2 and JSP1.1
----------------------------------<br />| SCJP, SCWCD, SCBCD, SCEA, SCJD |<br />----------------------------------
SCJP, SCWCD, SCBCD, SCJD, BB Java2 and JSP1.1
SCJP, SCJD, SCWCD, OCPJBCD