Connection Object for lock/unlock...?

[Sai Prasad]

I am not sure. I got 51 out of 53 for the server. May be this is part of general considerations where I lost 16 points! I will let Mark give his thoughts on this one.

[Debra Bellmaine]

Guys,
This is how I'm doing it, and please comment as appropriate.
Client always makes the same calls to server to handle any update to database records:
>lock
>read
>modify
>unlock
My client, after the initial startup, never knows or cares which mode it is operating in. The beauty of interfaces allows my client to talk directly to Data when in local mode, and to RemoteData when in n/w'd mode - but Client doesn't know which reference he's got.
As to locking when in local mode, since Client has a reference to Data itself when in local mode, and my Data's lock() and unlock() are empty, it makes the calls but no actual locking is done. In n/w'd mode, Client is going via the RemoteData, which is really a proxy and passes all the file i/o calls on to Data, but passes the lock() and unlock() calls to LockManager.
This seems clean and straightforward to me. I'm starting to see the light at the end of the tunnel, so if anyone sees any flaws in this, fire away.
Debra

[Mark Spritzler]

Sai, I really do think this is one of the areas where you lost points.
When you use MS Word on your machine does it lock records. I know MS WOrd isn't a database with records, but you don't need locking here because you are the only one using it. However if 5 people in your office all share the document on a file server, you need to make sure that if one is editing it the others can't.
It's also like Version Control. The main reason to have it is for multiple programmers so that one programmer doesn't overwrite the changes of another, and loose so great code.
However, if you are programming yourself, you have no need to worry about it.
Now, don't get me wrong in that you can use Version Control if you are a single programmer to help with restoring to past versions etc. I am just making the point that local means locking is an overhead.
Debra. That's fine because no actual locking is occuring, but couldn't you just as easily in your localDataAccess implementation not call lock or unlock at all? meaning have that code stripped out?
Mark

[Debra Bellmaine]

Mark,
Maybe I'm missing something, but Peter said the following in another thread:

For example, the client-side object in question could simply be the RMI stub for a DataInterface implementation that actually lives on the server (for specifics, search this forum for the "Connection" approach).

If the RMI stub is the localDataAccess, and it simply exposes on the client the public methods from Data(which implements DataInterface), then I don't see how I would be able to not call lock/unlock without some semaphore on the client to indicate mode. Maybe I have a wrong definition for localDataAccess?
Debra

[Mark Spritzler]

If the RMI stub is the localDataAccess

Maybe I have a wrong definition for localDataAccess?

There you go. In local mode there is no RMI, no server running, nothing. It is local, just like your MS Word documents are on your machine and you don't need any server software to get your document.
Local Mode is accessing the Data class directly, so to speak.
Mark

[John Smith]

Mark said:
That's fine because no actual locking is occuring, but couldn't you just as easily in your localDataAccess implementation not call lock or unlock at all? meaning have that code stripped out?

I don't like to argue with the bouncers, ehr... moderators, but this issue with locking/not locking in local mode looks like a catch-22 situation:
If you lock in local mode, you might lose points for the overhead. And if you don't lock, you might lose points for not complying with the requirements (for implementing lock/unlock in Data). I guess it's the matter of choosing the better of the two evil.
If you ask me, I'd say that leaving the lock/unlock methods empty in Data class is a gross insubordination. And if you do lock in local mode, you can always explain it in the design document (e.g. ...to provide for the future functionality, such as batch job reservations, or to run using a separate thread)
Eugene Kononov.

[BJ Grau]

Has anyone considered using a facade on the client side with business methods that call on your DataAccess locally or remotely, and decides whether to do locking based on the access mode?
To avoid having if statements in each method, you could have a LocalFacade and RemoteFacade both of which implement FBNFacade, which are gotten by your client from a factory based on the access mode. Your client gets a FBNFacade from the factory, and doesn't need to know if the underlying class is LocalFacade or RemoteFacade, it just calls the business methods like bookFlight, and locking is then only done when concrete object is a RemoteFacade.
This might be too much design. I'm curious to hear what everyone thinks.
[ May 27, 2002: Message edited by: BJ Grau ]

[Mark Spritzler]

I ahd a facade on my client side, so the GUi and it's controller know nothing about Data, Local, Remote just bookFlight(), saveBookedData(), and getAvailableSeats().
Here is the code I used in my implementation of my DataAccess interface.

     public void lock(int record) throws DatabaseException{
        //In Local mode this method does not need to do anything
    }
    public void unlock(int record) throws DatabaseException{
        //In Local mode this method does not need to do anything
    }
 

As you can see they do nothing.
In my remote implementation there is code for lock and unlock, and passes calls to, in my case Data, but in the better design, to LockManager.
Mark

[Jason Voegele]

Originally posted by Mark Spritzler:

The is absolutely NO LOCKING in local mode. In local mode the app has exclusivity to the Data classes and db.db file.

Do you say this because you think it implies a complication in design, or that it's a waste of resources, or both?
As for the first point (complicated design), I don't think it's necessarily an issue. I've implemented a LockManager that has two methods:
public void lock(int record, Object lockHolder);
and
public void unlock(int record, Object lockHolder);
In remote mode, calls to these lock and unlock methods are called from the "Connection" object like this:
lockManager.lock(myRecord, this);
In local mode, I can use this same LockManager class and call the methods from Data.java like so:
lockManager.lock(myRecord, Thread.currentThread());
I really like this approach, and I think it is one of those situations (like implementing Unreferenced for connections) where you get much improved functionality basically for free. Why
not add it?
If you feel that it is simply a waste of resources to implement locking in local mode, I counter with the fact that the database is intended to be reused by other applications and we cannot predict whether or not those applications would require multi-threaded access.
I, for one, will be implementing locking in local mode. As I've said, if you modularize your code appropriately, you get it basically for free anyway.
Your thoughts?
Jason Voegele

[BJ Grau]

Jason -
You said:

If you feel that it is simply a waste of resources to implement locking in local mode, I counter with the fact that the database is intended to be reused by other applications and we cannot predict whether or not those applications would require multi-threaded access.

The decision to lock/unlock in local mode should not affect the reuse of your database. The facility to perform this can be available, its just a question of whether or not the lock/unlock methods are called in local mode for this application.
When did you download your assignment? I'm asking because I bought mine recently, and the requirements don't say anything about code reuse.

-BJ

[Mark Spritzler]

I think the biggest mistake is to mis-interpret the requirements/definition of local mode.
I took it as meaning exclusive/local on one machine only no other running programs in the same VM.
That is why I feel lock in local mode is unnecesary code.
Also the following is from the instructions.html file

In this mode, the database and user interface run in the same VM and no networking is performed, and no sockets should be created.

The key here is the same VM. So if you have all this locking in the one VM, and the user runs a seperate program which also uses the db.db file, how does this new program know that you have a lock on a record in the first app. You can't, so therefore again it does nothing.
I don't want you to think that by calling lock or unlock in local mode will have you lose points. I can't guarantee that. I just think that looking at what you have, you can see that calling lock in local mode will have no affect or purpose or need to any app outside the VM, or that another app will run in the same VM that needs to also use the files.
My motto, KIS. You don't need the last S.
Mark

[Nate Johnson]

I assume you have finished the test... would you mind posting your score for the server section (sorry if you have done this already, I am a bit new here) since you did not have code in your local lock/unlock methods.
Thanks!

[Nate Johnson]

That was for Mark

Originally posted by Nate Johnson:
I assume you have finished the test... would you mind posting your score for the server section (sorry if you have done this already, I am a bit new here) since you did not have code in your local lock/unlock methods.
Thanks!

[Mark Spritzler]

Sure Nate I got a 49/53. These were the only points I lost in the cert. The points I lost was because I added two methods to the Data class that should have been in the CriteriaFindBuilder class, and becuase I didn't split the db and server into two seperate packages. I put them both into the db package.
Mark

[BJ Grau]

Mark -
I'm guessing that you were using CriteriaFindBuilder to accomplish the task of formatting the search criteria String before passing it to the criteriaFind of Data? That way the criteriFind method receives a search criteria String that is readily usable and doesn't contain any extraneous characters like "'"?
Is this correct?

[Mark Spritzler]

Yes that is correct.
Mark

[Ramesh kumaar]

Hello All,

[Ramesh kumaar]

Hello All,

Inorder to handle the client crash while unlock. Why dont we introduce a method
bookTicket as follows which intern does lock,read,modify,unlock sequencelly.
bookTicket(int recNo,int seats)
{
lock(recNo);
read(recNo);
modify(recNo,seat);
unlock(recNo);
}
In the above case i think there is no need to worry about client crash, Because once the client try to book a seat it has to unlock in any case.
comments are welcome.
thanks & regards,
-rameshkumar

[Sai Prasad]

You are right about the sequence. But during that sequence, a client can vanish due to many reasons before unlocking the record. More than that Sun accessors will test the client crash conditions. So I recommend you consider the client crash in your design.

[Mark Spritzler]

Did you ever get the feeling that this is the one thread that never seems to go away.
My suggestion for the future, if you have a new question or one related to original thread question that it should be posted in a new thread.
Thanks
Mark

[Matthew Comer]

BTW, I scored 153/133 and I did implement locking in local mode. The only two points they took off were for my db converter, which was a requirement in an older version of the assignment. So, by example, I would say that implementing locking in local mode will NOT necessarily decrease your score.
I did document my reasons for this decision in my design choices doc...
Oh, and I did delegate the actual locking work to a LockManager class.
Matt
[ June 10, 2002: Message edited by: Matthew Comer ]

[Ramesh kumaar]

Hi Prasad,
I sun spec they never mension about handling client crash. Please tell me is it needed
to handle.
If so is there any other way to handle it appart from unrefferenced Interface. Because i used the above and i come to no that unrefferenced () method is never called here iam using JDK 1.3.1

-rameshkumar

[Mark Spritzler]

Unreferenced default time to run is 15 minutes. Did you wait 15 minutes?
Unreferenced is the best solution for this assignment, once it is implemented, it is the only thing you need for handling client crashes.
Sure you could do more, but why take that extra time when it wasn't requested.
Mark

p.s Please, please, everyone, if you have a new question here, post it as a new thread, not adding to this already long thread that just won't die.