Jevgeni Zhukov

Originally posted by Iv�n P�rraga:
It works in the same lan... Well, I hope it is enough.

Well, it is, the network connection works. I tested my application only in LAN.

Try to test the application between two machines in the LAN. If it succeeds you have nothing to worry about.

Originally posted by Chris Bicnal:

Let's say we have two clients, client A and client B.
Client A performs a search.
Client B performs the same search.
Client A books record 1, eveything is fine.
Client B decides they want to book record 1....what happens?

You should show some kind of message that the record is already booked and not overwrite the previous booking. The system will be useless if a booked record can be overwritten by any other client.

[ September 25, 2008: Message edited by: Jevgeni Zhukov ]
[ September 25, 2008: Message edited by: Jevgeni Zhukov ]

I did not use value objects, because String array is simple enough and you can keep the implementation dynamical (no need to hard code the db schema).
As to validation, I only checked every fields' length and complience to 8 bit US ASCII.

Before starting a new thread you can search this forum for something similar.
Look what I found here

My suggestion is:
* Create similar interface as provided by Sun, but with all methods throwing RemoteException in addition.
* Make your implementation of Sun interface to implement this new interface as well.
* Make your remote interface to extend this new interface (then it will be empty)
* As to remote implementation class - initialize Sun's interface with local implementation class.

Originally posted by Ericsson Liu:
Does that mean i do not need to worry about locking on read/write to the db file since RandomAccessFile takes care of it?

No, it means that you do need to synchronize on those operations so that only one thread can read/write at a time.

If you are planning to use RandomAccessFile for reading/writing data, then reading/writing operations should be in synchronized context.
Imagine a scenario when two threads are trying to read from different locations of the data file - one gets pointer to read from one location and then the other moves the pointer away to read from another location.

I would suggest not to use any cache at all. Imagine the data file is so big that your application ran out of memory while creating a Map.
I didn't use cache nor value objects in my assignment and got max points for database layer. Just try to keep your solution as simple as possible.

The only method I entirely synchronized was deleteRecord(). In find() method I only synchronized getting of database length. In other methods: read(), update(), create(), I only synchronized a block of code responsible for checking and reading/writing record.

Hi and welcome to Javaranch!
I used
System.nanoTime();
for lock cookie value.

Here is some information on the issue:
The Mysterious 44/80 locking score

I had URLyBird 1.2.1 assignment:
24 classes (incl. 3 interfaces, 2 enums)
76 lines of text in Choices.txt
80 lines of text in userguide.txt

Hi
That is OK if you change those comments to Javadoc, IMHO you have to do that.

I used the location in the data file as recNo/record ID.
While creating a new record I was iterating over records finding the first deleted one. I never threw DuplicateKeyException.

As to validation, I only checked every fields' length and complience to 8 bit US ASCII.