Jevgeni Zhukov

Greenhorn
+ Follow
since Aug 28, 2008
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 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

for lock cookie value.
Here is some information on the issue:
The Mysterious 44/80 locking score
13 years ago

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.