• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

why is it necessary for unLock() to check clientID?

 
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am quite confused about the lock and unLock thing on why the clientID is even an issue. They would always be called in first lock, then unlock
fashion, why is it even required to consider: when try to unlock a lock by different thread? Seems to me that would never happen.
and what should I use for clientID since it's required to do it SUN way
Thanks for your comments.
 
Ranch Hand
Posts: 234
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A network accessible database that allowed clients to unlock records that they had not locked in the first place would be a very brittle system. Without some sort of control in place you have to trust your client code to always follow the rules. Bad idea.
 
town drunk
( and author)
Posts: 4118
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Eric,
There are two approaches to getting Client lock ID(I�m going to assume that you�re handling your networking by using RMI).
The first is the use the ID of the thread doing the calling. This is the method that I prefer, since it seems to be SUN's goal in providing the method signature that they did. The drawback here is that a RMI implementation could, arguably, be implemented that didn't use the same thread ID for locking that it did for locking. However, to my knowledge, this is a purely theoretical objection, since no such RMI actually does so.
The second approach is to change the method signature on the lock/unlock, and explicitly passing in a client ID. The advantage here is that you're not tied into your networking implantation, that thus have a more robust solution. In a production enviroment, where I had some leeway, this is probably the way I would choose.
The disadvantage here is that you risking an automatic failure, since you're not, by definition, implementing the methods lock(int) and unlock(int), but rather two different methods, with different signatures, that you find to be more convenient.
Which one you decide to go with is your call. In the past, people have scored well with both approaches.

All best,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
[ March 08, 2003: Message edited by: Max Habibi ]
 
eric zhao
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Max! I actually bought your book as my studying guide for this certificate test. It's a great book, thank you very much and OHIO STATE rocks!
Sadly, graduated from cleveland state, I end up as a programmer at another OSU (oklahoma) tough time for java newbies, I am happy at least I have a job and doing java programming that I like.
Thanks again for your help.
 
eric zhao
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, BJ:
Thanks for your comments. I didn't think about that the DATA part of this could be given out as a product. In that case, it makes sense to shield it with this ID thing. I was just thinking the whole thing as a product and thought we should hide lock/unlock all together.

And still quite hard to imagine a case where a developer would want to unlock something he didn't lock?
Thanks.
 
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm glad this issue came up. I'm using a class called LockTable which has two elements, String ThreadName which contains the name of the Thread which owns the lock and boolean lockStatus to indicate if the record is locked. I check who's trying to lock/unlock a record before any database manipulation occurs. On remote connection, THE NAME OF THE THREAD FOR A CLIENT CHANGES from one operation to another. I don't seem to have a unique threadname to compare. I'm on Windows 2000 box.
Am I doing something wrong or what can I do?
 
Max Habibi
town drunk
( and author)
Posts: 4118
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Duane,
Thread name's not guaranteed to be unique. Have you considered using the Thread reference itself? Remember, it's just a reference, so storing it is lightweight. Also, I'm suprised that the thread name changes. May I see the part of your code that stores the threadname, and the part that checks it?
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
[ March 09, 2003: Message edited by: Max Habibi ]
 
Duane Riech
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'll try changing the String ThreadName to
Thread threadId.
I was testing on Thread.currentThread().getName(). I didn't realize it could change.
Thanks.

public class LockTable
{
private boolean LockStatus; /* Indicates whether a database is locked
or not. */
private String ThreadName; /* Thread ID of thread owning the lock. */
public synchronized void lockRecord( ) {

LockStatus = true;
ThreadName = Thread.currentThread().getName();
} /* ...end of method lockRecord()... */

/**
* This method determines if a Thread already owns a lock on a particular
* database record. If the record is owned by the executing Thread, true is
* returned. Otherwise, false is returned.
* @return boolean value indicating if the executing Thread owns the lock
* on a record.
*/
public boolean ownsLock( ) {
/*
If the executing Thread already owns the lock, return true.
*/
if ( ThreadName != null &&
ThreadName.equals(Thread.currentThread().getName())) {
return true;
}
/*
The record already has a lock owned by another Thread, don't allow access.
*/
else
return false;
} /* ...end of method ownsLock()... */
}
 
Max Habibi
town drunk
( and author)
Posts: 4118
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Duane,
Let's start with basics, most of which will be redundant to you: I just want to establish a basis for discussion.
A given thread is really just s bundle of instructions. Your program may have any number of these bundles. You get one by default when you run the main(String args[]) method, but it can spawn others.
Now, when multiple clients try to access your server through RMI, one of two things happen.
1) they all come in on the very same thread.
2) each client is given a distinct thread.
since 1 can be thought of as a specialized case of 2, I'll concentrate on 2.
When client A connects to your server, RMI generates a Thread(remember, a thread is a bungle on instructions), that handle anything that client A wants. We'll call this thread A.
When client B connects to your server, it also gets it's own thread. We'll call that thread B.
So, if your lock method has a habit of saying: 'gee, let me get access to the current thread(A or B, in our case), and see if the record it's interested in is free. If so, then create a mapping entry that associates that the current thread to whatever record it wants. If not, wait until it is free, then create that mapping entry�.
Then, your unlock should say 'gee, the current thread is trying to unlock record number X. Is the current thread the one that is associated with record X in my mappings?'
Now, if your RMI implementation happens to have a single thread that handles the calls for every client(that is, thread A handles calls for client 1, client 2, etc.,), you�re still ok, because thread A won�t start working for client 2 until it�s done working for client 1.
Now, there are some people who read the java specification to mean that RMI could allocate one thread for part of client 1�s requests, and another for another part of client 1's requests. While this is open to debate (look over my previous posts if you want to see that debate), I don�t believe that there is any debate about the fact that no know RMI implementation actually does so.
Let me stop here, and see if all of this is clear.
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
 
Duane Riech
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I suppose so. Keep going....
 
Duane Riech
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
However RMI handles the communication back and
forth between the client/server, there has to be
SOME unique ID to identify who/whom to send each
packet to?
If RMI wants/doen't want to change threads to do
it fine. But there must be some unique tag.
 
Max Habibi
town drunk
( and author)
Posts: 4118
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Duane Riech:
However RMI handles the communication back and
forth between the client/server, there has to be
SOME unique ID to identify who/whom to send each
packet to?
If RMI wants/doen't want to change threads to do
it fine. But there must be some unique tag.


Well, yes. However, RMI has no responsibility to make that hypothetical tag available to you. Thus, RMI switiching threads like that would be a deal breaker, as far as this solution algorithm is concerned.
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
[ March 09, 2003: Message edited by: Max Habibi ]
 
Max Habibi
town drunk
( and author)
Posts: 4118
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The challange is for you to keep track of the thread that locked a given record. To do that, you need access to whatever thread is making a locking request, by using

method. This static method returns a reference to the current thread that is trying to drive the lock/unlock method(or any method, for that matter).
Thus, for locking, you might create an association between this thread and the record it's trying to lock by putting that information into a map. I would suggest a static map structure that is shared by all instances of the Data method.
Something like

Your unlock method simply checks the that the Thread.getCurrentThread() method returns a reference to the thread that locked recno, and then unlocks it.
Make sense?
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
[ March 09, 2003: Message edited by: Max Habibi ]
[ March 09, 2003: Message edited by: Max Habibi ]
 
Duane Riech
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
First, I apologize for not getting this...
You first state that there's no guarantee that
the same thread will be used for a client, then
you state in a example to use Thread.currentThread()???
I've just done some testing using this call...
You don't get the same ID. So whether you use a
simple algorthim or a map or whatever, you can
never compare thread's to know when the correct
thread is requesting to unlock.
So I just don't see what the map does for me.
RMI is not thread safe? Fine, but never supplying
a tag for each client is communicating to....
That's odd.
 
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


The drawback here is that a RMI implementation could, arguably, be implemented that didn't use the same thread ID for locking that it did for locking. However, to my knowledge, this is a purely theoretical objection, since no such RMI actually does so.


In my tests, I conclusively proved that Sun's RMI is up to its specification, -- RMI runtime makes no guarantees with respect to mapping remote object invocations to threads.
Here is the output of my simple test (I can post the source if anyone interested), where I create 2 clients, and each client makes 10 invocations of the same method:
client 1 used thread Thread[RMI TCP Connection(6)-209.91.62.136,5,RMI Runtime]
client 1 used thread Thread[RMI TCP Connection(6)-209.91.62.136,5,RMI Runtime]
client 1 used thread Thread[RMI TCP Connection(6)-209.91.62.136,5,RMI Runtime]
client 2 used thread Thread[RMI TCP Connection(7)-209.91.62.136,5,RMI Runtime]
client 1 used thread Thread[RMI TCP Connection(6)-209.91.62.136,5,RMI Runtime]
client 2 used thread Thread[RMI TCP Connection(7)-209.91.62.136,5,RMI Runtime]
client 2 used thread Thread[RMI TCP Connection(7)-209.91.62.136,5,RMI Runtime]
client 1 used thread Thread[RMI TCP Connection(6)-209.91.62.136,5,RMI Runtime]
client 2 used thread Thread[RMI TCP Connection(6)-209.91.62.136,5,RMI Runtime]
client 1 used thread Thread[RMI TCP Connection(7)-209.91.62.136,5,RMI Runtime]
client 2 used thread Thread[RMI TCP Connection(6)-209.91.62.136,5,RMI Runtime]
client 1 used thread Thread[RMI TCP Connection(7)-209.91.62.136,5,RMI Runtime]
client 2 used thread Thread[RMI TCP Connection(6)-209.91.62.136,5,RMI Runtime]
client 1 used thread Thread[RMI TCP Connection(7)-209.91.62.136,5,RMI Runtime]
client 2 used thread Thread[RMI TCP Connection(6)-209.91.62.136,5,RMI Runtime]
client 1 used thread Thread[RMI TCP Connection(7)-209.91.62.136,5,RMI Runtime]
client 2 used thread Thread[RMI TCP Connection(6)-209.91.62.136,5,RMI Runtime]
client 1 used thread Thread[RMI TCP Connection(7)-209.91.62.136,5,RMI Runtime]
client 2 used thread Thread[RMI TCP Connection(6)-209.91.62.136,5,RMI Runtime]
client 2 used thread Thread[RMI TCP Connection(6)-209.91.62.136,5,RMI Runtime]
As you can see, client 1 and 2 use the threads (6) and (7) interchangably, without a particular pattern.
My strong recommendation is to abandon the use of threads to identify the client and follow a standard RMI Factory approach for this assignment. This is the approach favored by a majority of people in this forum, and for a good reason, -- this is a simple, elegant, reliable, and standard solution to a standard problem.
Eugene.
[ March 09, 2003: Message edited by: Eugene Kononov ]
 
Max Habibi
town drunk
( and author)
Posts: 4118
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Duane Riech:
First, I apologize for not getting this...
You first state that there's no guarantee that
the same thread will be used for a client, then
you state in a example to use Thread.currentThread()???


Not exactly. It is my interpretation that you will always get the same thread from RMI per client. However, there are people who feel that it would be possible to write an RMI implementation that does not do this: either way, I believe that both side agree that there is no such implementation: that is, you do always get the same thread ID. Since I don't want to discount their argument simply because I disagree with it, I am mentioning it.


I've just done some testing using this call...
You don't get the same ID. So whether you use a
simple algorthim or a map or whatever, you can
never compare thread's to know when the correct
thread is requesting to unlock.


Duane, you are free to disregard my advice if it's not helping you. I've had students earn perfect scores using exactly this algorithm, but maybe I�m not the right source of help for you.


So I just don't see what the map does for me.
RMI is not thread safe? Fine, but never supplying
a tag for each client is communicating to....
That's odd.


No in the way that you�re describing, no.
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
 
Max Habibi
town drunk
( and author)
Posts: 4118
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Eugene Kononov:

In my tests, I conclusively proved that Sun's RMI is up to its specification, -- RMI runtime makes no guarantees with respect to mapping remote object invocations to threads.
Here is the output of my simple test (I can post the source if anyone interested), where I create 2 clients, and each client makes 10 invocations of the same method:
<snip>
[ March 09, 2003: Message edited by: Eugene Kononov ]



Hi Eugene,
I'd very much like to see your tests, as opposed to just their output. And I agree with you about the advocatacy of using the RMI factory. As a matter of fact, it's a linchpin on the approach. The factory is a remote instance, and it creates a unique remote data instance, one per client. Maybe I didn't explain this clearly before. Make sense, or should I provide an example?
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
[ March 09, 2003: Message edited by: Max Habibi ]
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


I'd very much like to see your tests, as opposed to just their output.


Here is the complete source, very short and sweet, just 4 java files:

Eugene.
 
Max Habibi
town drunk
( and author)
Posts: 4118
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Eugene,
Just as I suspected, you're binding several threads to the very same object, thus bypassing the factory all together. In looking over my own post, I think I can understanding how this impression could be reasonably formed. My apologies for not being more clear.
I may not be explaining the approach very well: I'm putting together an example that does so now, hopefully without giving too much away. But the basic premise is that the factory creates a unique remoteData object per client. The contention is that each of these remoteData objects is, in turn, beholden to a single client, and a single thread. Thus, one thread per remote instance.
HTH,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


Just as I suspected, you're binding several threads to the very same object, thus bypassing the factory all together.


Oh, so you are saying, "use the RMI factory, and use the thread as a client id?". But what's the point? If I have a connection object from the factory, then that object itself identifies the client uniquely. I don't need any thread ids anymore!
The bottom line, again, is that RMI runtime makes no guarantees with respect to mapping remote object invocations to threads. This is not just a theoretical argument from the RMI spec, but a very verifiable and practical one. I hope we aree on that.
Eugene.
 
Max Habibi
town drunk
( and author)
Posts: 4118
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Eugene Kononov:

Oh, so you are saying,


No, I am just saying, Inspector Cousou


"use the RMI factory, and use the thread as a client id?". But what's the point?


I'll explain the point, if you'll gather in the parlor.


If I have a connection object from the factory, then that object itself identifies the client uniquely. I don't need any thread ids anymore!


I'm not talking about the thread id, I'm talking about the thread reference. There's a big difference.


The bottom line, again, is that RMI runtime makes no guarantees with respect to mapping remote object invocations to threads.


While this is true, what it actually means is debatable, which is the point of this discussion. Some, including you and I and everyone else I know who is involved in this discussion, agree that it means that for a given remote object with n clients, there is not guarantee that that the object will consistently be called by thread t on behalf of client c. If it has multiple clients, it might, in fact, be called from various threads.
Others, and this is the part that's open to debate, feel that it means that for a given remote object with a single client, that object might still be called by various threads on behalf of that single client.
The part that is not open to debate, AFIK, is that there is no known implementation of RMI that actually will call a single remote object, which is bound to a single remote client, on various threads. Makse sense?


This is not just a theoretical argument from the RMI spec, but a very verifiable and practical one. I hope we aree on that.
Eugene.



Well, we do, but I�m afraid that we won't. That is, if it is verified through the example I will provide, I hope that you will agree. if it is refuted, then I will agree with you. Feel free to run the example on any OS. Deal?
All best,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
[ March 09, 2003: Message edited by: Max Habibi ]
 
Max Habibi
town drunk
( and author)
Posts: 4118
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Eugene,
You are correct, and I was mistaken. It is, in fact, possible for a single client, bound to a single remote instance, to have it's methods called by various threads. May I have some salt with my crow?
My apologies,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
 
Max Habibi
town drunk
( and author)
Posts: 4118
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
[UPDATED]
Duane,
My apologies on any confusion I've caused on this issue. It seems that you will, in fact, need to either modify the signature of the lock method, so that it can accept a client ID, or use the this object, in the data class, to act as a key.
The latter requires the use of the RMI factory pattern, as Eugene suggested. Again, please accept my apologies. The success of some of my students with that method, along with my own observations with other jdks, led me to a false conclusion.
best wishes,
M
[ March 10, 2003: Message edited by: Max Habibi ]
 
Ranch Hand
Posts: 92
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Max,
You said

The disadvantage here is that you risking an automatic failure, since you're not, by definition, implementing the methods lock(int) and unlock(int), but rather two different methods, with different signatures, that you find to be more convenient.


After this dissuction should I leav the lock and unlock in Data and implement it in a lockmanager. Is that ok?
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


It seems that you will, in fact, need to modify the signature of the lock method, so that it can accept a client ID.


Just to clarify something, -- the fact that you can't rely on threads to identify the clients does not mean that the signature of lock/unlock needs to be modified. A common solution here (seems like a consensus solution) is to leave the lock/unlock methods in Data empty, and implement them in RemoteData as follows:

The "this" reference points to the connection object created from the RMI factory.
Eugene.
 
Max Habibi
town drunk
( and author)
Posts: 4118
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Raffe,
That's one way to go, but it's not neccessary. The same idea as discussed above, but storing the this object as the key, instead of the thread, will allow you to adheare to the signature of the method. It's a minor tweak, codewise. Would you like an example?

M, author
The Sun Certified Java Developer Exam with J2SE 1.4
 
Max Habibi
town drunk
( and author)
Posts: 4118
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree that you can use the this, per my modified post this morning, though I would use the this as a key, and the record num as the value.
However, not implementing the lock method in data seems a little drastic to me. Why not implement lock/unlock in the data class, and use delegation in RemoteData? That way, you're adhearing to the specs.

M, author
The Sun Certified Java Developer Exam with J2SE 1.4
 
Raffe Paffe
Ranch Hand
Posts: 92
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Eugene , Max
Thanks you both for you coments. I must say that I am confused about lock/unlock in Data. Currentlly I have not implemented anything in Data. But now (after this topic) I feel that I must.
Eugene , can you say that people have passed the exame without implementing anything in Data (lock/unlock)?
My code looks like this now. This is the RemoteDataImpl.

and here is the LockManager:
Now, how should this be transformed into Data?
Max, could you provide the example you were talking about?
Puh! This subject got me nervous! :-)
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator



Max Habibi wrote:
Eugene,
You are correct, and I was mistaken. It is, in fact, possible for a single client, bound to a single remote instance, to have it's methods called by various threads. May I have some salt with my crow?


Well, the only person who never makes mistakes is Peter den Haan. Sometimes I think he is not human.



Max Habibi wrote:
However, not implementing the lock method in data seems a little drastic to me. Why not implement lock/unlock in the data class, and use delegation in RemoteData? That way, you're adhearing to the specs.


Yes, that seems like an obvious approach and that was how I designed it initially. However, that implies that locking will occur in non-networked mode.



Raffe Paffe wrote:
Eugene , can you say that people have passed the exame without implementing anything in Data (lock/unlock)?


Yes, I am one of these people, and I got a maxumum score for my server design with this implementation. Your lock manager and RemoteDataImpl code look fine.
Eugene.
[ March 10, 2003: Message edited by: Eugene Kononov ]
 
Raffe Paffe
Ranch Hand
Posts: 92
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Eugene , a followup. Did your specs. say :

Following is a description of the package that is provided, and of the extensions you are expected to implement.
[...]Part of your assignment will be to enhance the Data class. You may do this by modification or subclassing, but you should document the approach and reason for your choice.

English is not my native language so i am unsure...
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


English is not my native language so i am unsure...


What's the question?
Eugene.
 
Max Habibi
town drunk
( and author)
Posts: 4118
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Eugene Kononov:
[QB]
Yes, that seems like an obvious approach and that was how I designed it initially. However, that implies that locking will occur in non-networked mode.


The way that you ended up with is actually the way I started with. However, I ended up changing it. My reasoning is this:
1. The instructions say that you need to implement the lock/unlock methods in data. They are very specific on this point.
2. There are other methods, like add and delete, that while available, are not used. lock/unlock can easily fall into that category.
3. The local implementation does not need to call lock/unlock.
The strongest of these arguments, to me, was the first.
All best,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
 
Raffe Paffe
Ranch Hand
Posts: 92
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok, thanks all for your answers. I choose to inplement lock/unlock in Data. Now, how do i do that?
 
Ranch Hand
Posts: 126
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello.
One question regarding the lock. I've read many posts concerning this subject. The instructions specific say that you must implement the lock/unlock in the data class. If we change the method signature we risk to break existent code in use, so why don't we create a lock manager class when we open a database and we use it inside the lock(int)/unlock(int) with a reference to the Data class to get the client ID (this way we can use this class in a multithreaded environment). Besides this we add two new methods to the Data class that besides the record number also accepts a object that will be used as client ID and these methods also calls the lock manager?
This ways in a remote data implementation we use the new methods with the remote reference as client ID and in a local data implementation the original methods are used.
Thanks,
Miguel
 
Raffe Paffe
Ranch Hand
Posts: 92
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Miguel ,
Do you mean that we create a method
public void lock(int record, Object clientId)
and let that method call public int lock(int record) somehow ? As I read the spec we must implement lock in public int lock(int record).
Any comments??
 
Miguel Roque
Ranch Hand
Posts: 126
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello.
What I mean is, you have two classes, LocalDataImpl for local access and other RemoteDataImpl for remote access. Both classes have instances of Data class and define all the public interface of the original Data class (i.e. the method lock(int)/unlock(int)).
Inside these methods you call in local implementation the methods lock(int)/unlock(int) in the Data class and in the remote implementation you call the methods lock(int,Object)/unlock(int/Object) that also are in the Data class.
I'm considering this implementation due to the fact that Data class is thread safe, so can be used in a multithreaded environment even in local mode, so two different threads can operate on the same record meaning that we must have some way to lock/unlock the records.
With this implementation, specific javadoc comments should be placed in the Data class so that a final user should know the methods to use when locking records if in local mode or remote mode.
Comments please.
Miguel
 
Raffe Paffe
Ranch Hand
Posts: 92
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Miguel,
I think i understand your implemenation but what will you send to lock(int i). Is it the recordid or the clientId ?
Now, my question. The spec says:

public void lock(int record)
public void unlock(int record)
Record locking must be implemented using the methods public void lock(int)
and public void unlock(int)


So can you implement the locking using lock(int,Object)/unlock(int/Object) ? I dont know. Can we figure out a way to not add lock(int,Object)/unlock(int/Object) to data ?
 
Miguel Roque
Ranch Hand
Posts: 126
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Raffe.
You can implement lock(int,Object) outside the Data class. In your local data implementation you will have something like:

While in remote data implementation you have two options. Using the new methods of Data class that accepts the client ID will be:

If using the lock manager class outside the Data class, something like the following:

By putting the two new methods in the Data class, we avoid the creation of two objects that where LockManager inside the Data class and a LockManager inside the RemoteDataImplementation.
Miguel
 
Raffe Paffe
Ranch Hand
Posts: 92
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Miguel,
I understand. Thanks.
But

Record locking must be implemented using the methods ....


I understand the use of the lockmanager and so on. But can we implement locking somewhere else if you look at what they are wrinting ???
 
Max Habibi
town drunk
( and author)
Posts: 4118
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Raffe Paffe:

Max, could you provide the example you were talking about?
Puh! This subject got me nervous! :-)



Sure. A word of explanation. There are three important classes here: the rest are interfaces, and self explanatory.
  • A FactorypImpl that creates a generic factory, used by all clients, to get a remoteData object.
  • RemoteDataIampl that provides the functionality of a remote object. It offers two methods, doStuff and undoStuff, that might look familiar.
  • ClientDriver that creates 20 separate threads. Each thread creates gets a remoteData object by using the Factory. The then doStuff, wait a bit, then undoStuff.
  • to run the example, type in the following


  • One of the important things to notice here is that this design, the RemoteDataImpl classes uses the client itself as a key. Thus, you get free releasing of locks if a client dies. If you want more on this, read about weakHashMaps, which are a great little gem.
    FactoryImpl

    RemoteDataImpl

    ClientDriver

    Factory


    HTH
    M, author
    The Sun Certified Java Developer Exam with J2SE 1.4
    [ March 11, 2003: Message edited by: Max Habibi ]
     
    Don't get me started about those stupid light bulbs.
    reply
      Bookmark Topic Watch Topic
    • New Topic