Louis Logan

+ Follow
since Dec 18, 2006
Merit badge: grant badges
For More
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Louis Logan

Originally posted by Song Jing Lim:
If so, we need to use regex, don't know java.util.regex.* package are allow or not...

There is nothing in spec preventing regex use.

Coming to main topic..
I wonder if it would be safer to implement the findByCriteria method
just as mentioned in spec. AND implement another find method, which
is actually used in the code.
It is meaningless to have a method never referenced, but at least it does not break the spec.

My UI for B&S assignment search is:

For name, location field 'fred' matches 'Freddy' or exact match may be enforced.

For owner field, 'fred' matches 'Freddy'. (No exact match option)

rate and size fields do numeric comparion (>, >=, =, < or <= may be selected)

specialties field is regex enabled.
Without regex, 'Heat' matches 'Air Conditioning, Heating'.

I am not sure if the above violates the requirement (it does not exactly
conform to the javadoc of 'findByCriteria' method in interface ).

Appreciate suggestion if above implementation leads to automatic failure..

And the idea behind this search mechanism was:
Make the serach flexible. Let CSR specify any of six fields.
It does not make sense to match '3' with '30' for size field. A numeric
comparison is more practical.
Also for comma separated 'specialties' field , CSR would rather look search
like ' is there any contractor doing Heating? ..'

Sugestion appreciated.
[ January 07, 2007: Message edited by: Louis Logan ]

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.

Hm.. is it ok just to mention that the server does not keep track of
client crashes and go ahead ?
I have the one instance of remote object bound to registry.
If a client crashes, how do I identify it?

I let the user optionally set the lock timeout period(or not enforce it).

But not sure if it is a clean approach.
Help appreciated.

Shall I fail if I use jdk1.4 (not 1.5) and just test it out with 1.5 ?
[ December 22, 2006: Message edited by: Louis Logan ]

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.

Did you complete school or a drop out?
Thread has its working variable that is written back to main memory when it is swapped out (either release a lock or rescheduled by thread scheduler).

So one thread would retain the modified file pointer when it leaves 'run' state.

Its no exception (as mentioned by Chris) to wake up without a notify.

Originally posted by Joe Zhou:
for sure, lock.wait() will block till it is notified. This is the most interesting part of the assignment.

Do you expect the crude write method to be atomic ???

What if
Thread 1 writes partially to rec#1
Thread 2 writes partially to rec#2
Thread1 comes back to write the rest. Where would be your file pointer ???

try your code with 10 threads and 1 sec sleep. you would notice something ..

[ December 20, 2006: Message edited by: Louis Logan ]
[ December 20, 2006: Message edited by: Louis Logan ]

Originally posted by Joe Zhou:
To thread-safe your update():
update(recNo);//no need synchronize this block.

Your file pointer would go crazy if the low level write operation in update(recNo) is not in synchronized context

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..".

I think you need to implement database server code only from scratch.
You can (and should) re-use the schema.
In other words, ignore the requirement statement ..

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.


We are going further away from my question...
I do not see it as above. lock()/unlock() methods in this assignment are not indispensable to make data access thread safe.
But this design may be used to implement thread safe ,concurrent access to database even if you want to break your data access in multiple units. I.e.
Lock() => do a part of data access => say you are pre-empted here ..=> do second part .. => ... => unlock()

Of cource the 'part of data access' stuff had to be done under synchronized context.

Thats the way I see it. Correct me if I am wrong.

My question was,
Can the data access work done outside a synchronized context ever ?
Otherwise my design does not allow more than one thread working on data file at any instant !!

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?

Are lock/unlock methods tpresent to to guarantee atomic IO operation??

I thought they are there to implement logical record locking ONLY.

I can carry out atomic IO put putting code inside synchronized context.

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.

If I synchronize on a separate object (say a hashmap), I can implement concurrent read/write to database.

I agree about the coarse and fine grain stuff with record locking. I can implement concurrent access and prevent dirty write if
I simply do the following

synchronized(some static unrelated hashmap) {
write on the database;
// or read from database

Well I guess the above still allows concurrent read/write.

With record locking can I do without performing the read or write operation
outside synchronized context??

If not, then without wait() implemented, all reading threads would compete and eat resource... so what do I gain by NOT implementing record lock for reading ?
[ December 18, 2006: Message edited by: Louis Logan ]

Originally posted by Jeroen T Wenting:
The application is a booking application, not an application for administering the subcontractor information.

I wonder why did they have createRecord in the interface.

[ December 18, 2006: Message edited by: Louis Logan ]

I face some questions while writing the choice.txt.

Regarding locking, I have one RAF file(data server bound to RMI once). All crude operations (readRecord, update etc) are done in synchronized context since file pointer is being shared.

I am locking a record logically before update ONLY because of instuctions in specification. Technically there would be no deadlock without logical record locking since the read/write are done atomically.

Now I am not locking a record logically before reading because I interprete it as optional from specification.

Concern is, logical lock or not, at most one thread is going to read or write at any instance !! Is there a way to escape that ??

Do I show save complexity or show wise decision by not locking records before reading ??

I felt, if I do do not lock, the blocking threads would consume recource. Whereas by followin the locking scheme in writing, they release and wait.