Starting out - 2 Q's

[Bruce Ichiban]

Howdy,
I'm just starting out on my dev assignment and there are a couple of questions I have. I looked through the posts and I didnt see an answer, so i was wondering if someone could share their thoughts. If the answer to any of these is: just do whatever you want, and just document it, thats fine too!
1) Unlock: it says "If an attempt is made to unlock a record that has not been locked by this connection, then no action is to be taken." Does this mean, i need to prevent a client from unlocking a record that a different client locked? if so, does anyone have any ideas about how to track users? IP address isnt enough...no way to get thread ID's or ID's based on RMI or socket connections?
2) the local vs network modes: can someone elaborate on what this means exactly? i understand local means single user access only, but how do you do it "without networking"? does the client applet connect directly to the DB file? does this just mean that the client and the server run on the same computer, just diff VMs(this doesnt seem that different - b/c for networking, it doesnt matter where the client is...)
any elaboration and thoughts will be most appreciated!

[Peter den Haan]

1) Yes, that's what it means - and tracking client identity is one of the hotter topics in this forum. Briefly, all solutions I've seen so far take one of the following three approaches:- (a) give each client a unique, server-generated ID and have them pass it to lock() and unlock(), modifying the method signatures; (b) ignore the requirement completely; (c) give each client its own remote connection object. You can pass with any of these three approaches (yes, even (b)) although the elegance of your solution will influence the marking. Please search through the forum for details and discussion.
2) Local mode means a single JVM talking directly to the database file. No networking doesn't only imply a single JVM, it also means that it should completely bypass RMI and UnicastRemoteObject.
- Peter

[Martin Habicht]

hi

1) Peter, thanks for the clarification with the 3 possibilities of tracking client ID's. I understand all of them, but now it comes to the problem of choosing ONE.
earlier I thought of choosing simple b), but now that you mention I'd probably loose points, I rather choose c) - which seems to be the most elegant choice. Do you think I'd loose points with solution a) too?
2) do we ever use lock(-1) in our application? and if so where? lock and unlock make sense and criteriaFind is perfectly situated for the origin/destination filter. Or should my local client lock whole db? makes no sense to me...
(i read and understood the posts about a seperate lockfile for local use)
- Martin

[R Bischof]

Hi,
1) I think c) is the wa to go as it gives you one big benefit:
If a client dies abnormally the distributed garbage colletion allows you to be notified of this with some delay. That way you can remove any pending locks.
2) ne we don't and it does not really makes sense for tis assignment - at least not in mine ;-)
just my $0.02
rainer

[Martin Habicht]

thanks...
to be able to remove locks of a dead client, do I use the following approach or is there something better?
my UnicastRemoteObject (of which every remote client gets its own instance, just as in solution c) implements java.rmi.server.Unreferenced.
if unreferenced() gets called by RMI RE i release all locks by this client. (it's probably not worth to build my own datastructure (like e.g. a linked list) to keep track of locks per client, is it? well, it would be more scalable though...)

- Martin

[Peter den Haan]

We had an interesting discussion about the use of Unreferenced a week or two ago. It is a fine safety net, and even better, you get it almost for free, just a few lines of code. It is not suited to implement the sort of short-lived transaction timeout you encounter in application server environments, but arguably you shouldn't want that in a DBMS server like the one we're building here anyway.
- Peter