Originally posted by Song Jing Lim:
If so, we need to use regex, don't know java.util.regex.* package are allow or not...
Originally posted by Jeroen T Wenting:
You can't detect it. You can only detect if there are any connections to the Remote at all, not where they are coming from, so you cannot determine whether any specific client is still connected or not.
Originally posted by Joe Zhou:
I am wondering you two are fresh graduate. I see you are using so much theories from school. I feel sad that I have left from school for so long.
What I am doing is coding the project as the specification and testing the code according to the project requirements. I would never finish my assignment if I dig into the theories so deep. Hope this is not too superising.
Originally posted by Joe Zhou:
for sure, lock.wait() will block till it is notified. This is the most interesting part of the assignment.
Originally posted by Joe Zhou:
To thread-safe your update():
lock(recNo);
update(recNo);//no need synchronize this block.
unlock(recNo);
Originally posted by Henry Le:
Hi all,
First question: In my spec, there is a requirement which I am not quite to understand .."The new system must reimplement the database code from scratch without altering the data file format..".
Originally posted by Joe Zhou:
Think that if 'synchronize' can solve all the problems, there is no need to implement the lock()/unlock(). It is not a sense of logic locking. It is something a must to make your code thread-safe.
Hope I am correct.
Originally posted by Joe Zhou:
Simply putting the IO access code may not guarantee the IO operation is thread-safe. That is why lock()/unlock() are required. Right?
Originally posted by Jeroen T Wenting:
no, locking and threading have little to do with one another (though locking does help keeping the threading code performant).
You can have locking and still not be threadsafe, and you could provide threadsafe code without locking.
The lock is to prevent one client to attempt a modification to a record while another client is doing so.
That's a far more coarse grained operation than a lock which prevents multiple threads from gaining access to the same program resources.
The logical lock you program on a record can hold against a broad range of resources simultaneously, resources that are completely unrelated to the work that goes on by synchronising on something.
You could for example write code to enable simultaneous reading and writing to the database using a record level lock to prevent simultaneous updating.
You could never do that by synchronising database access on the file, as that would prevent concurrent access to the entire file.
Originally posted by Jeroen T Wenting:
[qb]
The application is a booking application, not an application for administering the subcontractor information.
qb]