Should this situation happen?

[Ken Kirin]

Hi All,

I am wondering about these statements in my spec whether it is conflicting with my design that

Keep in mind that networking must be entirely bypassed in the non-networked mode.

Does this mean if a local client application is running, a network client application can not be run, also the database server application?

not use the network server code at all

and

the program must allow the user to specify the location of the database, and it must also accept an indication that a local database is to be used, in which case, the networking must be bypassed entirely.

So I implied this is the issue between local and network client application,right? How about the server? Running the database server application is also considering a part of networking according to those three statement above? If not, it is possible to run a local client application on the server machine using a database file location while starting a database server application with the same location of the database file as its local client application is using. Is this situation breaking any requirement of the project? My implementation is to have different lock objects for the local and network client application. If this could be a case, I need to determine which lock object should actually be used for this local client application; so, it might be a case that this local application will use the lock object for the network one instead.Thank you very much for you reply.

Regards,
Ken Kirin
SCJP
SWCD
SCJD(B&S 2.2.1.. In progress)

[Liang Anmian]

There are 2 modes: networked mode and standalone mode.

What the specs mean is, if you are using networked mode, the database resides on another server (in this case, the server which is running the JAR file with the "server" argument). In other words, in order to interact with the database, you need RMI/Socket codes (depending on which approach you have chosen).

For standalone mode, it means that you must allow the client to select a local database file to use. "Local database file" simply means that the database file resides on that very client's machine this time round, instead of another server. After specifying the location, interaction with the database will occur DIRECTLY without involving RMI/Socket codes, thus the meaning of "bypass".

So what does involve mean in this context? If you are using Sockets, involving Socket code simply means that you are interacting with the database using Socket objects and the respective input and output stream objects. If you are using RMI, involving RMI code simply means that you invoke a method using an object stub. So, if you are running standalone mode, make sure that your codes does not rely on networked code to function, else it is an immediate failure.

So, how do you decide at runtime whether to connect to another server or not? How do you decide whether to use direct connection or RMI/Socket codes? Well, all I will tell you at the moment is, design patterns to the rescue! For a start, take a look at the Adapter pattern (which I'm not using at the moment, but I realized many are using it) and Factory pattern.
[ March 10, 2005: Message edited by: Liang Anmian ]

[Ken Kirin]

Hi Liang,

Your explanation was very clear . Actually my primary concern is about running local application on a SERVER machine. Here is the scenario

ON A SERVER MACHINE
===================

Runs a database server application by setting the server database file for servicing its remote clients at c:\db2x1.db

Runs a local client application and selects the local database file at c:\db2x1.db

Now both applications are sharing the database file, before getting a lock object in the local client application it can check whether the local database file and server database file is actually the same by looking into the property file.

if the address is the same( this is a special case ) then my DataLockManager will return a network lock object to this local client application instead of returning a normal local lock object.

If it is not the same, then returns the local lock object.

the network lock object in this case will help protect multiple threads accessing the same record number one from a remote client application of another machine and another from a local client application.

Regards,
Ken Kirin
SCJP
SWCD
SCJD(B&S 2.2.1 In progress)

[Liang Anmian]

I see that you got B&S for your assignment. I got that too, but mine is version 2.1.3.

According to my specs, I'm supposed to assume that at any given time, only one program is accessing the database file. Do check yours too.

[peter wooster]

Originally posted by Ken Kirin:
ON A SERVER MACHINE
===================

[list]Runs a database server application by setting the server database file for servicing its remote clients at c:\db2x1.db

Runs a local client application and selects the local database file at c:\db2x1.db

Now both applications are sharing the database file, before getting a lock object in the local client application it can check whether the local database file and server database file is actually the same by looking into the property file.

My instructions were very clear that you don't have to worry about two programs directly accessing the database at the same time. It was in the section entitled "Locking" and said:

"You may assume that at any moment, at most one program is accessing the database file; therefore your locking system only needs to be concerned with multiple concurrent clients of your seur server."

[Andrew Monkhouse]

Hi Ken,

The following situation should not happen.

Originally posted by Ken Kirin

Runs a database server application by setting the server database file for servicing its remote clients at c:\db2x1.db

Runs a local client application and selects the local database file at c:\db2x1.db

To do so would contradict the following line in your instructions:

From the instructions
You may assume that at any moment, at most one program is accessing the database file

Regards, Andrew

[Ken Kirin]

Thank you guys. My spec said that too.

Regards,
Ken Kirin
SCJP
SCWCD
SCJD(B&S 2.2.1 In progress)

[Steve Schooler]

 
    The following situation should not happen.
 
        quote :-o	 riginally posted by Ken Kirin
 
            * Runs a database server application by setting the server
              database file for servicing its remote clients at
              c:\db2x1.db
            * Runs a local client application and selects the local
              database file at c:\db2x1.db
    To do so would contradict the following line in your instructions:
 
        quote:From the instructions
    
            You may assume that at any moment, at most one program is
            accessing the database file
                            
I originally interpreted the instructions differently.  The need for
locking presupposes that two remote clients could be "logged in" to
the database simultaneously.  Therefore, I interpret the instructions
to mean that programmer is allowed to give user lock of entire
database even if in real world, lock might be constrained to portion
of table.
 
Based on my (reasonably motivated but arbitrary) interpretation of the
instructions, the instructions do not preclude standalone app and
remote app running simultaneously.  Since I'm inexperienced, I could
easily be misinterpreting, and I invite comments, especially re below:
 
    Trottier - Exam Cram 2 J2D (isbn = 0-7897-2992-X) p 93 states that
    insert row locking (IRL) is necessary only in remote mode, not
    local (standalone) mode.
        
Clearly, either Trottier or I am mistaken; I wonder which?
 

[Andrew Monkhouse]

Hi Steve,

Welcome to JavaRanch and this forum.

Based on my (reasonably motivated but arbitrary) interpretation of the instructions, the instructions do not preclude standalone app and remote app running simultaneously.

I think the only way that this would be possible, is if the standalone application and the server application are both the same application. That is, one of the following must occur:

When you start the application in alone mode, the server starts in the background.

When you start in server mode, the standalone application starts in the foreground.

Under any other circumstance, the client and server will be running in different JVMs. Which means that you will have two programs accessing the database file (contradicting the instructions).

I do not think case 1 is logical. If the server starts automatically in alone mode, then why bother having a server mode? Plus, if this were a real life application, I would expect the client to have asked for the standalone application first (so they can ensure it works / get used to the interface / make (the inevitable) change requests). While the client is doing all this, we would be working on the server software. So I would expect alone mode to mean exactly that - no networking at all.

Similarly, why would you want to run a standalone version of the software when the networked server starts? If the network server is running, why wouldn't you run the network client? You gain nothing by running a standalone client at this time, and might cause yourself problems since you are starting an application that appears to be always running (depending on your implementation you might not be able to shut down the client application since the server is running in the background).

With respect to Alain Trottier's book, he is correct that the locking is only necessary in networked mode. However I personally prefer to have the locking code in both networked mode and standalone mode, simply because it allows me to have a single code base for both systems.

Regards, Andrew
[ March 18, 2005: Message edited by: Andrew Monkhouse ]

[Steve Schooler]

 
    quote:  Under any other circumstance, the client and server will
            be running in different JVMs. Which means that you will
            have two programs accessing the database file
            (contradicting the instructions).
                        
Interesting; I hadn't considered JVM's.  From instructions:         
                    
    quote:  You may assume that at any moment, at most one program is
            accessing the database file; therefore your locking system
            only needs to be concerned with multiple concurrent
            clients of your server.
                        
Last portion of above (+ Trottier p 93) support your interpretation.
However, I (STILL) interpret above's use of ACCESS to refer to
specific data retrieval/update, and NOT mere "connection" to database.
This interpretation implies that different JVM's may simultaneously be
"linked" to database file, but may not be simultaneously
retrieving/updating the data.
 
Proper interpretation requires:
1.  Real world experience with terminology, which I absolutely do not
    have.
2.  Report from those who scored high on locking.
 
I'll score higher if Sun feels that I haven't misinterpreted and
haven't tried to "reinvent wheel".  Request more guidance.
 

[Jeff Bosch]

Hi, Steve -

Why do you place your entire post within code tags? That's usually meant only for code snippets.

Just curious...

[Steve Schooler]

No other way to specify pre-formatting. Some forums allow [pre] ... [/pre], but JavaRanch doesn't seem to. Code box soemwhat misleading, but seems preferable to UNcontrolled formatting. Tightly controlled indentation often needed for clarity.

[Andrew Monkhouse]

Hi Steve,

Originally posted by Jeff Bosch:
Hi, Steve -

Why do you place your entire post within code tags? That's usually meant only for code snippets.

Just curious...

Originally posted by Steve Schooler:
No other way to specify pre-formatting. Some forums allow [pre] ... [/pre], but JavaRanch doesn't seem to. Code box soemwhat misleading, but seems preferable to UNcontrolled formatting. Tightly controlled indentation often needed for clarity.

Personal preference I guess. I don't think you really loose anything in what you have posted so far by using the UBB [QUOTE] tags. Just for the sake of the exercise, here is how I would have handled your last post (you are free to continue the way you are posting though):

----------------------------------------------------------------------------

Originally posted by Andrew Monkhouse:
Under any other circumstance, the client and server will be running in different JVMs. Which means that you will have two programs accessing the database file (contradicting the instructions).

Interesting; I hadn't considered JVM's. From instructions:

From Sun assignment instructions:
You may assume that at any moment, at most one program is accessing the database file; therefore your locking system only needs to be concerned with multiple concurrent clients of your server.

Last portion of above (+ Trottier p 93) support your interpretation. However, I (STILL) interpret above's use of ACCESS to refer to specific data retrieval/update, and NOT mere "connection" to database. This interpretation implies that different JVM's may simultaneously be "linked" to database file, but may not be simultaneously retrieving/updating the data.

Proper interpretation requires:

Real world experience with terminology, which I absolutely do not have.

Report from those who scored high on locking.

I'll score higher if Sun feels that I haven't misinterpreted and haven't tried to "reinvent wheel". Request more guidance.

[Andrew Monkhouse]

Hi Steve,

Interesting point.

My interpretation is that "access a file" could correspond to "access a building" - in the first case, you attach to the file, in the later case you walk into the building. Your interpretation - reading a record - would correspond (in my interpretation) to going to a particular office within the building.

I don't believe it is practical (within the confines of the assignment instructions) to cater for the case where two separate applications can access the file as long as only one is accessing a record. To do so requires an agreed protocol between the two applications so that they know when it is safe to do their reads / writes. Since there is no way for us to communicate with potential other clients (or even know which language they might be written in) we cannot really do this.

Regarding your point 2: "Report from those who scored high on locking." - I will have to leave that open to anyone who wants to report on their scores in the current assignment. Many current candidates are scoring 44/80 for locking, but the hint from Sun makes it sound like the loss of 36 points in that category has nothing to do with the situation we are discussing. I did get 100% for my locking without worrying about this, but that was on an earlier assignment (Fly By Night Services).

Regards, Andrew