• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Need for lock expiration if DataAdapter is used ???

 
Vlad Rabkin
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,
I wonder if there is any need for Unreferenced/WeakHashMap if an DataAdapter class is used, which hides lock/unlock methods from GUI client (lock/unlock is invoked on the server, not on the GUI client)?
If the GUI client crashes a Data client (DataAdapter) will still succeed, since it is connected to the Data directly (not over sockets or RMI) !?
There is actually no way it can crash: If it crashes, the whole database server must be anyway restarted...
Tx,
Vlad
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Vlad,
How was it in Italy ? I am glad to see you back !
You are right. If you handle locks server-side only, within try..finally blocks, you shouldn't get some deadlock because of a client crash. My first lock design was based on that fact (when I was using Thread.currentThread()) as the lock owner). But as Max criticized my solution (forcing the locking server-side by design seemed to be too much restrictive as far as I understood our very short discussion about it), I had to change it for a much more complex design based on connections stored as WeakReferences (same principle as the Unreferenced / WeakHashMap solutions you mention). All that to tell you that I really don't know what to answer... BTW, where is Max ?
Best,
Phil.
 
Vlad Rabkin
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Phil,
How was it in Italy ?

Thanx, it was great, but too short ...
But as Max criticized my solution (forcing the locking server-side by design seemed to be too much restrictive as far as I understood our very short discussion about it)

Uppss... What do you mean? I thought that he critized using Thread.currentThread() reference, because it will not work with RMI. Now it seems that I understood it not correctly.
Does he mean that using lock/unlock on the server(that is what he done in his book) is not a good idea, because it is too restrictive for our assignement. So, we have to provide these methods in our DataAdapter interface. Is it what you/he mean?
Best,
Vlad
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Vlad Rabkin:
Hi Phil,

Uppss... What do you mean? I thought that he critized using Thread.currentThread() reference, because it will not work with RMI. Now it seems that I understood it not correctly.
Vlad

You're right Vlad, this is what I meant.
M
 
Vlad Rabkin
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Max,
Thanx for you reply.
How are you doing? I hope you fill now better after your poisoning accident?

Phil, then I don't understand what for you need WeakHashMap? I thought you invoke lock/unlock inside your DadaAdapter class on the server?
Best,
Vlad
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Vlad,
Uppss... What do you mean? I thought that he critized using Thread.currentThread() reference, because it will not work with RMI. Now it seems that I understood it not correctly.
Using Thread.currentThread() as the lock owner worked well with RMI (as well with my sockets implementation), as far as you handle locks/unlocks within a given method server-side, like this :

Even in RMI (RMI is not magic ), such a piece of code will still be executed by only one given thread. In case the client crashes, the finally blocks takes care of unlocking (OK), while in the middle, Thread.currentThread() is well a valid lock owner.
So I interpreted max's critique as that, by design, my LockManager class didn't support client-side locking. BTW I don't need it, but as I know that at least one (old ?) assignment forced you to implement the whole Data access client-side, I was afraid of my design restriction. Unfortunately, all of that are just guesses of my own, because Max stopped the discussion (I noticed that he is far less talkative with me than he can be with you - don't be jealous, Phil it's bad ! )
Regards,
Phil.
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Max !
Nice to see you back with us !
Vlad:
Phil, then I don't understand what for you need WeakHashMap? I thought you invoke lock/unlock inside your DadaAdapter class on the server?

I don't use any WeakHashMap, just connections objects (any Object which may represent a client connection in fact) wrapped as WeakReferences registred with a ReferenceQueue. It's a little different. And if you ask "why" again, it's just to get another lock "owner" than Thread.currentThread(), an object I may monitor (crashed ? Involved in some deadlock ?), with no restriction about where (server-side or client-side) locks are granted and released.
Best,
Phil.
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Guys,
Sorry I've been away for long: The food poisoning, the book, lectures, work, etc..well, the long and short of it is that I needed to take some time for friends and family. Anyway, I'm back: let the games begin
M
 
Vlad Rabkin
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Phil,
Using Thread.currentThread() as the lock owner worked well with RMI ...

Ok. I guess I know what the problem is:
It is dangerous if you decide to move lock/unlock (in future) so, that they are invoked from the user, but not inside Adapter.
GUI Client 1 calls lock(). Server Thread 1 picks up request.
GUI Client 1 calles update(). Server Thread 3 pick up request.
GUI Client 1 calls unlock(). Server Thread 5 picks up request.
So, there is no sense to track thread for locking.

So I interpreted max's critique as that, by design, my LockManager class didn't support client-side locking

What you say is you are afraid to use reference to Thread because if the design changes in the way described above it would work. It is correct.
But I don't see any reason to use provide lock exparation, just because if design changes it could be used. I think it is too much...
It is hard to discuss it because of possible misundersting of the problem by me or you. In any case I don't want to bring more uncertantly for you ...
I noticed that he is far less talkative with me than he can be with you

I think Max was in hospital last week, that is why he stopped discussed all topics, he was involved in. Moreover I think he is tired from all our ideas (I think both of us are guilty ), which bring more complexity and uncertanty without need...

Best,
Vlad
As I wrote this mail, he answered to yours one. It seems he is not tired from our ideas. Great, lets the games begin!
[ September 08, 2003: Message edited by: Vlad Rabkin ]
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Philippe Maquet:
Hi Vlad,
Uppss... What do you mean? I thought that he critized using Thread.currentThread() reference, because it will not work with RMI. Now it seems that I understood it not correctly.
Using Thread.currentThread() as the lock owner worked well with RMI (as well with my sockets implementation), as far as you handle locks/unlocks within a given method server-side, like this :

Even in RMI (RMI is not magic ), such a piece of code will still be executed by only one given thread. In case the client crashes, the finally blocks takes care of unlocking (OK), while in the middle, Thread.currentThread() is well a valid lock owner.
So I interpreted max's critique as that, by design, my LockManager class didn't support client-side locking. BTW I don't need it, but as I know that at least one (old ?) assignment forced you to implement the whole Data access client-side, I was afraid of my design restriction. Unfortunately, all of that are just guesses of my own, because Max stopped the discussion (I noticed that he is far less talkative with me than he can be with you - don't be jealous, Phil it's bad ! )
Regards,
Phil.


Hi Phil,
Let me see if I have this straight. Client C1->DataAdapter.book()? Is that correct? And is there one Data per client?
If so, then DataAdapter is a remote object? If this isn't correct, please draw it out for me.
Thanks,
M
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Max,
Let me see if I have this straight. Client C1->DataAdapter.book()? Is that correct?

Yes.

And is there one Data per client?

Yes too.
If so, then DataAdapter is a remote object?

If by remote object you mean an object instantiated server-side (I am not used to RMI technology yet, I use sockets), then yes.
Soory about that, but I posted my whole Locking design as an answer of one of your posts, but as it was just before you got sick, you probably missed it. Very shortly, I don't use Thread.currentThread() as the lock owners anymore, I replaced it by Objects (any sort of) which may uniquely identify client connections and which are stored as WeakReferences registred in a ReferenceQueue regularly polled to monitor crashed clients. It is multi-table by design and seems to work fine.
Best,
Phil.
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Phil,
I have a few testing suggestions for you, if you're interested.
sure you've tested with multiple clients. However, have you tested with clients who release their connection? That is, where your client count goes to, say, 12, then,6, then 10? Also, have you created artificially long delays between the various steps of your book method?
All best,
M
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Max,
I have a few testing suggestions for you, if you're interested.

Sure I am !
sure you've tested with multiple clients. However, have you tested with clients who release their connection? That is, where your client count goes to, say, 12, then,6, then 10? Also, have you created artificially long delays between the various steps of your book method?

Not yet. I have just finished with the network part, so the tests I performed till now were based on emulating multiple clients by multiple threads : on LockManager alone first, then on Data + LockManager together. Those threads claimed multiple locks randomly on many records (to increase the "chance" of deadlock situations and test their prevention), sleeped randomly, sometimes "forgot" to unlock records (to test unlock on timeout). Now a "killer" thread randomly decided to kill (interrupt) one of my tests threads while running, resetting their Thread object to null, to emulate crashed clients. Those Thread objects owned an Object (a simple : Object connectionObj = new Object()) representing the client connection and used as the locks owner. Well, once those killed Thread objects were eligible for garbage collection, I could noticed that their encapsulated connectionObj became weakly-reachable : LockManager got them when polling its ReferenceQueue and could clean their remaining locks up.
Of course, I'll now perform similar tests with real clients, using my new network code. But I am quite confident. If you've read the discussion I have with Andrew about sockets, you'll notice that I use permanent connections. A ClientConnection (or its encapsulated Session object which maintain database connection(s)) is a good candidate to be used as the connection object "weak-referenced" in LockManager. When a client crashes (proven in my metwork tests), my server is aware ot it within the few next milliseconds. The ClientConnection is then "lost" in such a way that no more strong references to it exist in the system. Becoming automatically weakly reachable, LockManager should handle them within the next second (it only polls its ReferenceQueue every second).
BTw, what about joining us in that thread on sockets ? We could benefit of your lights on a subjet which is so rarely treated on this forum.
Best,
Phil.
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My 'light' is dimming, but it's a nice thought .
I'll try to swing by, but in a cursory glance, it seemed that you guys were doing fine.
M
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic