Markus M�ller

Greenhorn
+ Follow
since Dec 06, 2003
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 Markus M�ller

Originally posted by Max Habibi:
Hi Markus,
As I tell me martial arts students, your goal is to win the fight, not prove that you're better/faster/smarter --though you probably are
M


Hi Max,
That philosophy is really reasonable!
Thanks alot.
Markus
Hi Max,
Regarding all those Discussions about the work-around of a client-gui-crash case (I mean using WeakHashMap or implementing the rmi Unreference interface), I also appreciate your choice of WeakHashMap.
But what would you concretely use as the "key" while calling the method
put(Object key, Object value) of that map object.
The "value" could be for example the recordNumber wrapped by a Long instance (new Long(recordNumber)), am I right?
But what about the key , I mean that must be something specific to the client's connection, so that recordNumber can be derefernced from the map, as soon as the connection is broken. but what could be that client-specific-uniqe-id.
Thanks
Markus
[ December 18, 2003: Message edited by: Markus M�ller ]
[ December 18, 2003: Message edited by: Markus M�ller ]
[ December 18, 2003: Message edited by: Markus M�ller ]
Hi everbody,
Concerning locked records I've got a question with a scenario as the following:
We're in the network modus, with two gui client connected to the network server (does not matter if implemented as tcp/ip socket or rmi):
- Client A locks a record for updating.
- Client B tries to get a lock and goes to the wait() until client A does a notifyAll().
- Client A's user is typing some information on his GUI to update the record (while holding the lock at the same time). now theoretical this client could lock the record for an indefinite time.
- And the gui by client B is still trying to get a lock for this record, while for example showing an indeterminate progress bar.
One approach would be to let the user B to press a Cancel button on his GUI, as soon as he finds out that the record is locked too long, but at the meantime we've invoked the lock() method already, and have no way to call cancelLockRequest() in an asynchronous manner (as far as DBAcess interface does not/should not provide such a method).
How could one solve this problem?
Thanks for any comment.
By the way, I forget to mark the topic with NX: prefix, as I'm also one of those folks trying to achieve this certification challange, so sorry for inconvenience.
[ December 06, 2003: Message edited by: Markus M�ller ]