aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes What about the locking manager? 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 about the locking manager?" Watch "What about the locking manager?" New topic
Author

What about the locking manager?

Joel Mata
Greenhorn

Joined: Oct 31, 2009
Posts: 25

Hi, I know this is a very old post…

When you have more than one thread, each thread has its own server instance which contains its own locking hash table mechanism, so my problem is, if you have two threads how the second knows that a record is locked if the first locked that same record in its own locking manager? Is the locking manager static?


ITIL V3, SCJP, Spring Core v3 and Going for the OCJMD
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5286
    
  13

In my application design I just have 1 Data instance (which is responsible for both locking and file manipulatons). If you have by design multiple server instances you'll need to share some information. Otherwise you won't have a multi-threaded application and you'll definitely fail for violating a must requirement.

Marking the locking manager as static is one of the possible scenarios.


SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
http://www.javaroe.be/
Joel Mata
Greenhorn

Joined: Oct 31, 2009
Posts: 25

Roel De Nijs wrote:In my application design I just have 1 Data instance (which is responsible for both locking and file manipulatons). If you have by design multiple server instances you'll need to share some information. Otherwise you won't have a multi-threaded application and you'll definitely fail for violating a must requirement.

Marking the locking manager as static is one of the possible scenarios.


I implemented a RMIServerFactory that is the object i register, in turn it contains a createRMIServer() :



The locking mechanism is a static class, which seamed to be correct… What made me doubt about my implementation is the fact that if the server does not unlock a record, by any reason, then all other clients will be blocked leading to "starvation", is this correct?

Everytime i call a lock i make the unlock inside finally, which i think will make sure that the unlock is always executed, still would "i don't like it"


Thanks for your comments.
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5286
    
  13

First of all in the createRMIServer method I would expect a return of server instead of the creation of another object. Secondly lock and unlock should only be used for updating/deleting a record, not for reading one.

On the starvation subject. Based on the RMI server factory pattern I assume you opted for a thick client. One of the drawbacks of this approach is when a client which owns a lock crashes for some reason this record will be locked forever and can never be locked by another thread/client. This is a drawback you should definitely consider (as you do at this moment ). But it's not always necessary to handle this in the code, you have a choices.txt (the decision document) where you can list this as one of the drawbacks and give some possible solutions to this problem. And that will be fine, you don't have to implement any of them. Just considering and showing that you put a lot of thinking into your design is enough.
Similarly I implemented a solution with a record cache (so reading file in memory). Of course with a very big file I can ran into memory issues. So I mentioned this in choices.txt and provide some alternatives to solve this issue (e.g. ignoring the records in the past). I didn't implement any of these alternatives (just my simple record cache) and passed with a perfect score.

(I moved your posts in a new thread, they deserve a thread of their own )
Joel Mata
Greenhorn

Joined: Oct 31, 2009
Posts: 25

Roel De Nijs wrote:First of all in the createRMIServer method I would expect a return of server instead of the creation of another object. Secondly lock and unlock should only be used for updating/deleting a record, not for reading one.

Am i not doing that already? That is, if the server already exists than i return the same instance. I only create the server once.
(some minutes passed…)
Yes, you are right, there is a typo in the code:


Roel De Nijs wrote:On the starvation subject. Based on the RMI server factory pattern I assume you opted for a thick client. One of the drawbacks of this approach is when a client which owns a lock crashes for some reason this record will be locked forever and can never be locked by another thread/client. This is a drawback you should definitely consider (as you do at this moment ). But it's not always necessary to handle this in the code, you have a choices.txt (the decision document) where you can list this as one of the drawbacks and give some possible solutions to this problem. And that will be fine, you don't have to implement any of them. Just considering and showing that you put a lot of thinking into your design is enough.

Think it i not the case, the lock/unlock is done in the server side (i say "think" i totally accept that i might be seeing things wrong):




Similarly I implemented a solution with a record cache (so reading file in memory). Of course with a very big file I can ran into memory issues. So I mentioned this in choices.txt and provide some alternatives to solve this issue (e.g. ignoring the records in the past). I didn't implement any of these alternatives (just my simple record cache) and passed with a perfect score.

By the way, why are so many people implementing the cache? I found manipulating the file very easy… Am i missing something?


(I moved your posts in a new thread, they deserve a thread of their own )



[edit] removed complete code snippet
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5286
    
  13

First of all, I changed your post a bit and removed the implementation of the bookAccomodation method. We prefer pseudo-code when complete methods are posted, because we try to prevent providing complete solution/logic (otherwise someone else can just copy/paste everything he/she needs to complete the assignment).

Let's start with the easy one. My main reason to implement record cache was: I don't have to handle the IOException in each CRUD-method. Another reason is that if 2-3 people say: "hey, I implement(ed) the record cache and that was so easy", it might influence people which are just starting their assignment. Because if they use this strategy, they will find more people to help them if they have an issue. In the Sun(ny) days (before Oracle acquisition) this certification was a lot more popular, so you had 5-10 people which were working on the assignment simultaneously, so much more traffic/questions in this forum. Nowadays it's just 1 or (if you are lucky) 2, sometimes even none for a couple of weeks. So people (have to) make more decisions on their own.

In order to answer the server side question, I need to know which methods do you expose to the client? The methods from the given interface? Or business methods like bookAccommodation and findAccommodations? If you expose business methods you'll have a thin client, otherwise it's a thick client. In a thin client starvation will never happen, because the server code always completes (unless a developer makes a mistake and forgets to unlock record for example).
Joel Mata
Greenhorn

Joined: Oct 31, 2009
Posts: 25

Roel De Nijs wrote:First of all, I changed your post a bit and removed the implementation of the bookAccomodation method. We prefer pseudo-code when complete methods are posted, because we try to prevent providing complete solution/logic (otherwise someone else can just copy/paste everything he/she needs to complete the assignment).

Fair enough

Let's start with the easy one. My main reason to implement record cache was: I don't have to handle the IOException in each CRUD-method. Another reason is that if 2-3 people say: "hey, I implement(ed) the record cache and that was so easy", it might influence people which are just starting their assignment. Because if they use this strategy, they will find more people to help them if they have an issue. In the Sun(ny) days (before Oracle acquisition) this certification was a lot more popular, so you had 5-10 people which were working on the assignment simultaneously, so much more traffic/questions in this forum. Nowadays it's just 1 or (if you are lucky) 2, sometimes even none for a couple of weeks. So people (have to) make more decisions on their own.

For the prices Oracle charges I can understand...


In order to answer the server side question, I need to know which methods do you expose to the client? The methods from the given interface? Or business methods like bookAccommodation and findAccommodations? If you expose business methods you'll have a thin client, otherwise it's a thick client. In a thin client starvation will never happen, because the server code always completes (unless a developer makes a mistake and forgets to unlock record for example).

For your words I'm sure I have a thin client.

Another question, being that I have only one server instance doing the synchronization at method level should be sufficient, right. I understand that I don't require the synchronization to be done in a unique object(like a static class in the Data class).

Many thanks for your comments.
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5286
    
  13

You can make access/manipulation of an object thread-safe by using different alternatives (e.g. mark methods as synchronized, use synchronized blocks, using concurrency api,...). This can only work of course if all threads work on the same object (when using synchronized methods) or synchronize on the same object (when using synchronized statements). If each thread uses its own copy of an object, the synchronization methods/statements have no purpose at all.
 
jQuery in Action, 2nd edition
 
subject: What about the locking manager?