Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Take this Testing Tool for Data Class

 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,
Having read all the replies I still did not get the answer on the question:
Should the update method(for example) of Data class have calls to lock and unlock methods.
My implementation of Data class' read, update and delete methods is:
lock -> do action -> unlock.
For this implementation the lock and unlock methods should actually be private. In this case client application will not worry about possibility of calling the lock/unlock methods itself as the methods are called internally. But we have been given the interface by Sun...
Obviously the original test posted here did not work for me when I tried doUpdate method because thread will lock record from doUpdate method and call my read method that tries to lock record again and can not because it is currently locked by the same thread ...
Yes, I can describe, as mentioned in one of the pprevious posts above, in my choices.txt that application does not suppose to call lock and unlock methods itself and i will limit this from the GUI side but I am not sure how Sun's automated tests work. So can anyone who passed the exam comment on my solution please ?
 
Ranch Hand
Posts: 152
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Dimirti Slyus:

Should the update method(for example) of Data class have calls to lock and unlock methods.



No, it should not. At least not in my assignment. My update method takes a cookie value as param, so obviously, it considers that locking has been done already before update is called.

Of course, it should verify the value of the cookie.

Hope it helps
 
rinke hoekstra
Ranch Hand
Posts: 152
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dear all,

a bit late, but still a reaction:

Originally posted by Mihai Radulescu:

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.



Yes, classical, but not typical to our assignment, I think. A client locks a record, and then just waits until the record is available. Why would you allow that same client to lock another record? As you said: just allow each client to only lock one rec at a time. Or is anybody allowing a client to work on other records while waiting for a specific record to be released?

I think the only deadlock situation which could occur to our assignment is the following scenario:

1. client A locks the HashMap of LockManager to do something.
2. client B locks the Database to do something
3. client A waits on the Database to be freed
4. client B waits on the HashMap to be freed

Which is a "problem" which can easily be solved by design: just use always the same order of locking, first the HashMap, then the DB. Which is also a very logical order.

The only problem which is then left is, that another programmer who might extend our code isn't aware of this. I think this is the only real risk on deadlock, and the sollution is just to document that programmers should always keep to this order.
 
Ranch Hand
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

About lock/unlock - the Data class is accessed by more than one user at once thats why it must guarantee synchronized access for the concurrent request. The lock manager provide this feature and you must use it on all the situation where the data integrity may be altered. The update method alter the data integrity so you must be shore that is treated in synchronized way.
In opposite the read method does not alter any data state so it does need to be treated the same like the update method. More even if your read is synchronize this will not help you a lot because after you read and you release the resource and try to show(render) it the with your GUI the data content still be changed.

now about the death lock prevention you can do :
1.constrain the user to lock only one record at once.
2.ordinate looks (rike solution).


Regards,
M
 
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Reading this discution, I realized that my locking implementation do not handle logical deadlocks. If I just document in my class that a client must own only one logical lock at a time, its OK to pass the exam, or I must implement logical deadlock handling?

Thanks,
Marcelo.
SCJP5(93%), SCJD (in progress)
 
Mihai Radulescu
Ranch Hand
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Marcelo

You don't need to handle the dead locks will be more simple to prevent them.

Regards
M
 
Marcelo Camargo
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Mihai,

You are right. But I thought again on my design and I think I don't have this problem, because I am using an adapter business class in the server, and exposing throught RMI just business methods.

For example, the update method in my business interface do:

1. get the logical record lock for record 1
2. make the update/delete in my database implementation for record 1
3. release the logical lock for record 1

As the client application will be waiting the end of the remote call (or local) to my business method, the same client will never have a chance to call another business method before the end of the current one executing.

What do you think? am I wrong?

Thanks,
Marcelo
SCJP5(93%), SCJD(in progress)
 
Mihai Radulescu
Ranch Hand
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Marcelo,

You are right but not 100%, consider this - your implementation provides one (or more) client for the Data Access Layer, but this does not means that this will be the only one, in the future new clients (for your Data Access Layer) may appear. If in your case (the actual clients) the actual design take care about the death lock in the future clients can have other design and the database must be able to treat all kinds of clients.

Regards,
M
 
Marcelo Camargo
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Mihai,

OK, folowing this way, this mean that I need to prevent that one client take more than one lock at the same time... But, how to do that? Now, my implementation does not identify a client (I am just identifying the client by the cookie I generated to him in lock method), and the code is very simple.

I am trying to think in how to identify the client:

- I can't use the client thread ID, because I am using RMI and many clients can have the same thread ID. And, even I use the thread ID, it is not a safe solution (even using TCP/IP), because (and now cames something that I think people are trying to ignore in this forum) a client can be a multithreaded client. So, in this situation, imagine a client that calls the lock method for record 1 using thread 1 (that arrives in server throught thread 1), and the same client, using another thread, calls at the same time the lock in record 2 throught thread 2 (before the server have returned the first call to the client). In this situation, you cannot block the lock in record 2, because you will think the second thread is another client, but is is the same client !

Do you have a solution?

Thank you,
Marcelo.
 
Marcelo Camargo
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To complement my last post, the other solution of "ordinate looks" will not solve the problem of have a multithreaded client. As I explained in the last post, a client can have multiple threads an use them to call the server, simultaneously, locking different records...
 
rinke hoekstra
Ranch Hand
Posts: 152
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Marcelo,

Originally posted by Marcelo Camargo:

OK, folowing this way, this mean that I need to prevent that one client take more than one lock at the same time... But, how to do that?



I think putting it in your javadoc is enough. If the new programmer doesn't read the javadoc documentation, well, then it is entirely their responsibility things go wrong.
 
Marcelo Camargo
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ufff... Thank you !!! I will have time for a beer

Best regards,
Marcelo.
 
Marcelo Camargo
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This test class is really good.

I found another error, if the main thread finish before the end of the other threads, the other threads stop execution.
It depends of the operation system (and the code need to run in any SO). I am using linux and I got this problem.
This can occur in any SO, but I think Windows implements threading different.

To avoid this situation, the start method need to join to each thread created:



Thank you for the class code!

Marcelo.
 
Mihai Radulescu
Ranch Hand
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Marcelo,

Sorry for the delay but I have a hell of the project on my head.
It is like this, the lock manager locks resources with ids (e.g record 10 is locked by id 1) the each user has its own unique id. So in this way you can know which user lock which resources. In this case you can :
1.check the lock order and by release you do it backwards - a little bit complicated
2.allows that one user locks only one record once. With other words a client tries can not lock a record when it has already lock a record, this constrains the user to use the follow work-flow : lock, operate, release. This has the disadvantage that the client can operate only one record at once but on the other side it is simple (to test and maintain).

The choice is yours.

Rinke,
Wrong, you can not be shore that the documentation(javadoc) will be read. To prove it try the negation technique. Lets say that you document it in the javadoc and the "junior programmer" does not read it and produce a death lock. In this point is lost even if it read the the documentation he/she/it does not has any clue about what's going on -(there is no DeathlockException to throw ) so only the javadoc is not enough.

Regards,
M
 
rinke hoekstra
Ranch Hand
Posts: 152
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Mihai Radulescu:

Rinke,
Wrong, you can not be shore that the documentation(javadoc) will be read. To prove it try the negation technique. Lets say that you document it in the javadoc and the "junior programmer" does not read it and produce a death lock. In this point is lost even if it read the the documentation he/she/it does not has any clue about what's going on -(there is no DeathlockException to throw ) so only the javadoc is not enough.



Hmmm, you think so? I would definitely also put it in choices.txt, but not in the user manual.
Anyway, I think the deadlock problem is highly overestimated, and the chances of it occurring are very small - at least with a decent design.

regards, Rinke
 
Marcelo Camargo
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mihai,

My lockRecord signature does return only the lockCookie to the client. I use the lockCookie to identify the client when it wants to unlock the record. I dont have this ID you sad for each client.
Then, if the same client calls lockRecord again, I dont know if it already have other lockCookie.

And, the thread id does not work for me, because, as I sad, I am working with RMI and many clients can share the same thread. Ans, even with TCP/IP, I couldnt be sure using the thread id, because if the same client uses two different threads to call the DBAccess, I cant identify it as the same client.



I dont understand how you identify your client, could you send your signatures?

Thanks,
Marcelo.
 
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have somewhat mutated the TestData tester into a Junit Test. Any assertion fails also show up in the log.

Disclaimer: use at your own risk. I acknowledge that there would be room for improvement, but please improve and share again.

https://coderanch.com/t/189353/java-developer-SCJD/certification/JUnit-Test-Cases
[ September 06, 2007: Message edited by: Chris Be ]
 
Ranch Hand
Posts: 231
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

thanks Sam for this testing tool, but I just wanted to mention that it we should put the invocation of unlock() in a finally block.

another thing for those who are instantiating Data (implementation of DBMain the interface given by Sun) for each client: data should be a member of RunTest.

thanks again and sorry for bring this (sort of) old topic back but I thought that would help.
 
He got surgery to replace his foot with a pig. He said it was because of this tiny ad:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
    Bookmark Topic Watch Topic
  • New Topic