GeeCON Prague 2014*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes B&S: locking methods in DBMain 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 "B&S: locking methods in DBMain " Watch "B&S: locking methods in DBMain " New topic
Author

B&S: locking methods in DBMain

Oliver Weikopf
Ranch Hand

Joined: Feb 17, 2004
Posts: 58
I'm having a hard time figuring out this interface thingy.

The DBMain interface seems to be for the server's access to the database file only - not for the client's RMI access to the server. From everything I've read around here this seems to be generally accepted.

My question is: Why then does the interface say about the lock method: "locks a record so that it can only be updated or deleted by this client"? Which client? If this interface is just used for file access, it is never used by a client, is it? It would seem to me that a locking method of this kind would only make sense in the RMI interface. Besides, there would be no way to identify the client that has requested the lock in this layer. Or am I missing something here? What have you guys made of this?
[ June 14, 2006: Message edited by: Oliver Weikopf ]
Samuel Ittera
Greenhorn

Joined: Jun 09, 2006
Posts: 9
In no means do this answer your question, but give this some thought.

In standalone mode, you are running only the client and not a server. This client needs to access the database. The DBMain interface provides an interface to access the database, which may or may not be running on a server.
Oliver Weikopf
Ranch Hand

Joined: Feb 17, 2004
Posts: 58
Originally posted by Samuel Ittera:
In no means do this answer your question, but give this some thought.

In standalone mode, you are running only the client and not a server. This client needs to access the database. The DBMain interface provides an interface to access the database, which may or may not be running on a server.


Yes, that's exactly what I'm doing. But this doesn't really solve my problem. I just don't know what to make of the sentence "Your server ... must provide locking functionality as specified in the interface above." or the one I quoted earlier. These sound as if the interface is to be used for the client-server communication, which isn't really possible. So far, I have the locking methods in the RMI interface. But my thinking is that they might need additional return values or parameters to identify the client. If I add those, I can't really use the methods in DBMain to actually carry out the locking, right?
Jeroen T Wenting
Ranch Hand

Joined: Apr 21, 2006
Posts: 1847
my implementation is a thick client, which does its own locking.
OTOH it know nothing about networking, leaving that to the interface layer which gives it a Data object which depending on the parameters it gets (network mode or standalone) is of different actual implementations.

So for the client there is no difference at all between network and standalone mode once the connection has been established.
It reads, locks, writes, and unlocks records.
To the database layer itself there's also no difference, it doesn't know about networking either.
It just gets calls from a connection, and couldn't care less whether that connection is a network connection or a standalone connection.
The only thing on the server that knows about networking is the connection layer, just like on the client.
By swapping out that small part of the client and server I can completely change the networking system without touching any of the other code.
I've even prepared the thing to allow for more networking modes than just RMI or local to exist side by side, though that's not implemented.


42
Oliver Weikopf
Ranch Hand

Joined: Feb 17, 2004
Posts: 58
Thanks, Samuel and Jeroen. While you didn't directly answer my question (probably because I failed to formulate it decently), your input has successfully pushed me in the right direction. I think I've solved this now.

I've just finished implementing the locking stuff in such a way that it is not client-oriented but exclusively thread-oriented. When a thread requests to work with a record, I simply make it wait, not caring about identifying a client. That way, even though it doesn't really make sense to use the locking mechanism if you're in standalone mode, it still works (so you can even think about a multi-threaded standalone version later on). Either way, the interface is correctly implemented and I don't need an additional layer that wastes its time identifying a client.

As it is, the only problem lies in the fact that anyone can unlock a record without possessing the lock. But the instructions and interface seem to agree with such behaviour and I am confident that's ok.
Jeroen T Wenting
Ranch Hand

Joined: Apr 21, 2006
Posts: 1847
locks are linked to cookies. Anyone having the proper cookie can do anything requiring the lock.
While that could be a security problem, solving that is likely outside the scope of the assignment (as the assignment in other places seems to exclude any security centric code, like when it says to not require RMI security managers, doesn't include user authentication and authorisation, etc).
 
GeeCON Prague 2014
 
subject: B&S: locking methods in DBMain