Frank Hardy

Greenhorn
+ Follow
since Aug 17, 2004
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Frank Hardy

Hi Jon,

gosh!! This puzzled me too! Additionally I'm not a native english speaker.
I used the encoding format "US-ASCII" and the results were fine. Just test it.


Regards,

Franky.
Hi Zee,

as I know brackets are a common syntax for commandline parameters to describe that a parameter is optional. Like placeholders for specific values which are in "lower-greater than" characters.
As you know: no parameter means to start the network client.

Hope this is a help for you.

Greetz,

Franky.
Hi Krzysiek,

I use inner classes too (I like them ) and I'm also unsure about this. Most of my inner classes are private and used as pure data structures. Hence, most of their member attributes are final and then I used not to implement the accessor methods for these attributes. I described it in the java doc. I hope this may satisfy the examiners.

Greetz,

Franky.
Hi Kang,

ok, I see. If you're using sockets then you have the full control about the threads. But I think with sockets you have to care more about the networking stuff. I'm wasn't familiar with both thematics so I decided to use RMI. And as I posted before I experienced a lot of trouble while handling with thread-ids.
That's the crux for RMI I think.
Nevertheless, yesterday I've found a solution for myself - I hope its final.

Greetz,

Franky.
Hi Kang,

if you are using RMI (as I am doing) you cannot rely on thread-id.
As far as I know RMI does not guarantee that subsequent requests from the same remote client are processed by the same thread in the server.
RMI is using thread-pooling. At the server site a number of threads are hanging around in a pool (having a party - which means they are alive - the whole time the server is running!). If a request is commin' in one of them is grabbed from the pool (lets say its Fred) to do something useful. If Fred is finished he's returned to the pool. If a further request is commin' in another thread may be grabbed from the pool (maybe because Fred is currently busied) to do the task. Ok. I just want to be funny ... erm.
The thing is: When a specific thread at a client is making subsequent requests at the server you cannot be sure that all requests are done by the same thread at the server. Threrefore, using an id of the thread is a risky and not recommendable solution.

!!! If anything I said before is incorrect someone must correct me !!!

This is very important when you dealing with hanging locks (caused by a crashed remote client). Detecting a crashed client does not work (in RMI) via checking the server-threads alive state (use instead the Unreferenced interface!). This is discussed in other threads in this forum.

The locking is primarily needed in the remote scenario to make sure that different remote clients don't access (in a modifying way) the same record concurrently.
If everything is running in the same VM (stand alone situation!) you don't need cookies. You only have to make sure that only one thread at a time is (write)accessing a record (maybe sync them on the record number).

Because I am using RMI for networking I experienced that it is no good to rely on threads directly. I am trying to sync them in some way but I'll avoid to identify them at any time in my code.
I am working hard on a solution for this problem.

Greetz,

Franky.
Hi Kang and Dan,

my URLyBird-Assignment is quite similiar. No word about that I have to allow concurrent reads.
One is for sure: if someone is trying to read a record while it is locked by a writer the reader has to wait until the writer is finished. And a writer can't write a record that is occupied by a reader.

Unfortunatly MY read-method doesn't has a cookie in the signature. Therefore I used to implicitly lock a record in the implementation of my read-method. At the beginning of the read-method I'm setting a lock and when the read-method is left the lock is cleared. This offers the possibility of using read-locks (because it's hidden in the impl). But this left me with some (still) unresolved problems.
In this case locking a record for modification (via lock) and subsequently reading it (via read) will/may cause problems as long the server is not able to identify that the same client tries to read access the write-locked record. The client may waiting for its own write-lock to be cleared.
Using the thread object for id is risky when using RMI (I decided to use RMI). And you have the standalone situation where everything is running in the same VM. And maybe the client-GUI is using worker-threads to avoid a blocking GUI which also can operate concurrently.

I'm still searching for a simple, clear and solid solution. And I'm sure that there are still some issues about that which I haven't regognized at all.
What is your opinion about that? Am I wrong? Do I have missed something?

Greetz,

Franky.
Hi all!

Basically I have the same opinion about i18n. But I think it is not good style when the texts for display are hard coded. Especially when the texts are spread all over the gui view code (depends on over how much compile units the gui views are spread). For maintainability it is important to easily locate the text definitions. If the texts are hardcoded it would be harder to find them. Maintainability (=quality) is desirable (in any software ).
For my assignment I don't plan to use the jdk's resource bundle mechanism but I plan to externalize my display texts in some way. I have yet no concrete concept how I'll realize it. Maybe it would be a good idea to define constants for all display texts of a view and concentrate them at one point in the code.
However, the best way is to keep it as simple as possible.
Do you know what I mean?

Greetz,

Franky.
Hi Darya,

I'm sorry. It wasn't my intent to affront you, but you wanted an explanation and I gave it to you.
My first approach was similiar to the post which has been linked by Olena. But I made a new decision and as I said before: maybe I'm wrong, maybe I'm not, maybe our requirements are different ... we'll see

Are we ought to let the client act only through the DB interface?



For sure NOT - I know that, and the others definitely too :roll: - but the topic of this post was about the database, its interface and its remtote-ability, not about further abstraction by creating a business interface which then is used by the client-app. Ok, I have to admit that my previous post could be misunderstood. My fault.

And, btw, I'm sure you can handle the problem. I'd never thought anything else.

Best regards,

Franky.
Hi Andrew,

okay I see. RMI is typically using thread-pooling. And therfore I cannot be sure that the same thread which locked a record does unlock it. Furthermore, the threads in a pool won't die. isAlive() doesn't work at all.
I think I have to redesign.

Never mind, design is fun...

Thanks a huge lot again for your hint.

Regards,

Franky.
Hi Darya,

ok, maybe I'm wrong.
You made a copy of DB and called it RemoteDB. RemoteDB has no relation to DB and hence it is not a DB.
The implementation of RemoteDB is RemoteData. Hence a RemoteData is a RemoteDB but no DB. But in my opinion the client-app should use always the DB interface.
For example: if you put an instance of RemoteData into the RMI-registry and you get it at the client-site, it is still a RemoteDB and no DB instance.

That's my opinion (and planned solution):
I think you need a second adapter class (used on the client-site) which I called here DB2RemoteDB. It adapts an instance of RemoteDB (your remote object RemoteData is such an instance). This adapter is an implementation of DB (like Data) and forwards (delegates) every call to the adapted (RemoteDB) instance.

During runntime - at the client-site - you wrap your remote RemoteData instance that you retrieved from the registry with an instance of the DB2RemoteDB adapter. And the client-app uses this adapter instance to make the calls to the database system. So, the client uses a DB instance and doesn't have to talk to a different interface in remote mode.

I hope my explanation was a little bit more clearly.

Greetz,

Franky.
Hi Darya,

I have a different assignment (URLyBird), but the situation for me is the same.
My approach to that problem is nearly the same (glad to see that others have the same ideas ) but I used to add another adapter (DB2RemoteDB) which adapts from DB to RemoteDB because I think the requirement is that the client-app has to use always the DB-interface (as given in the requirement spec). And as I can see, your current solution implies that the client-app has to use the RemoteDB-interface when it wants to talk to a remote server.
On the client side you need to have some kind of factory that creates a connection to a remote database or a local database.
Behind the scenes - in the case of a remote connection - the factory has to get a RemoteDB instance via RMI (maybe from a factory or directly from the Registry) and wrap it with the DB2RemoteDB adapter, which than will be returned.
So the client-app talks always to a DB-interface instance.

Using the adapter-pattern implies that when the DB-interface changes, the RemoteDB-interface has to be corrected to match the new DB-interface and the two adapters have to be corrected too. This involves 4 classes and because the adapters only delegate their calls it is not much overhead.

Do you(all) agree?

Greetz,

Franky.
Hi Andrew,

hmmmm...yes...you're d#mn right.
Aaah! How could I miss that? I'm thinking too much over that.
Thanks a lot for your hint.

But the "hanging lock" problem is noteworthly.
I've kicked my timer solution. Now I've substituted it by checking the owner thread-object of a lock if it is still alive (fortunatly it was not much effort). Locks that are owned by dead threads will be now removed automatically. This doesn't break the interface contract. As long a thread is alive it will hold its record locks. In the case a Programer (me) has forgotten to unlock the locked records or the thread is killed or dies without unlocking it record locks, the locks will be removed when at least another thread wants to lock the corresponding records.

Do you(all) think this is that a better solution?

Greetz,

Franky.
Hi Anusorn,

I've exactly the same assignment but I used an approach which is completely different from yours to deal with "hanging locks".
In my approach each lock has an expiration time which can be configured. My locks are represented by lock-objects and are managed by a manager instance. Each lock-object gets a timestamp (current system time) when it is created. Each time the lock manager is accessed it will check the timestamp against the current system time. The difference to the timestamp is calculated and when the expiration time limit is exceeded the lock is no longer valid and will be removed or substituded by another one.

I think this is a very simple and acceptable solution for this problem.

What do you(others) think?

Greetz,

Franky.