aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes synchronization- help me i am re-re-reimplementing Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "synchronization- help me i am re-re-reimplementing " Watch "synchronization- help me i am re-re-reimplementing " New topic
Author

synchronization- help me i am re-re-reimplementing

Dora Gal
Greenhorn

Joined: Jan 03, 2004
Posts: 15
Hello everyone,
I am almost ready with the application, but this is the 6th time I am implementing the Data class....

Suppose the thread A is reading/updating record 1. Can other threads read/update record 2 at the same time?

I dont want to keep the whole database in the memory so I decided to have a primary index table (Map: key is recNum, value is position in the file).

When reading/updating/deleting a record I get the position out of the primary index table and read/update/delete from the file with a RandomAccessFile.

May I synchronize on the position or simply on the primary index table? I

Waiting for any help,
d
Dora Gal
Greenhorn

Joined: Jan 03, 2004
Posts: 15
the question in a simpler way...

do you have


or

Anton Golovin
Ranch Hand

Joined: Jul 02, 2004
Posts: 476
For your locking question, if you are going to synchronize on the Data object, you need two things:

1) a private instance variable Map in a Data object
2) a Singleton-implementing Data class with all methods synchronized.

If you wish to syncronize on the Map itself, you need only one thing:

a public static Map in the Data class. You could have as many Data objects as there are clients, and the methods of the Data class do not need to be synchronized.

I am doing the second way:



At the end of this code, you are free to write and read from the file from the location of the record (your code should calculate the start and stop points) at will.

I have yet to encounter an opinion that this will not work. I am not sure, also, that you need to synchronize the Data object if you require record locks for reads and writes.

The code does this:

1) Try to acquire the lock on Map. Keep trying until the lock is acquired.
2) See if the record you want is locked. Wait until it is unlocked. (Each wait causes the lock on Map to be released and then re-acquired.) Lock the record. Unlock the Map.
3) Update the record in the database file.
4) Lock the Map. Unlock the record. Unlock the Map.

In my humble opinion, different threads can read and write to different, non-overlapping parts of the database file as long as they do not also modify the metadata - metadata being the descriptive information about the file. Records are locked and cannot be modified concurrently, but metadata cannot be locked and will be modified concurrently - resulting in a corrupted file. Therefore, the mode of RandomAccessFile for concurrent database access is rwd - read, write, and immediately update to disk.

I invite anyone who thinks this may not work to please put in a word. The cornerstone question is: Can a file be written to in different, non-overlapping places? Will that corrupt a file?
[ August 03, 2004: Message edited by: Anton Golovin ]

Anton Golovin (anton.golovin@gmail.com) SCJP, SCJD, SCBCD, SCWCD, OCEJWSD, SCEA/OCMJEA [JEE certs from Sun/Oracle]
mike acre
Ranch Hand

Joined: Sep 23, 2003
Posts: 197
In reply to Anton
Can a file be written to in different, non-overlapping places? Will that corrupt a file?


As I see it, every method that reads or writes to the file must be synchronised.

A method moves the pointer then reads or writes from that point. This must be guaranteed as one atomic operation. As such synchronising the methods in your file access object does the job perfectly.

So no, you can't have two threads concurrently writing in different, non-overlapping places. They must be queued with the aid of the objects monitor.


SCJP 1.4, SCJD
Satish Avadhanam
Ranch Hand

Joined: Aug 12, 2003
Posts: 697
Hi Anton
Originally posted by Anton Golovin:


[ August 03, 2004: Message edited by: Anton Golovin ]


In continuation to what I told in other thread about notifyAll() in lock method, here is what I think.

Thread 1 enters lock method, synchronize on lockedRecords and as soon as the control comes out of lock method, Thread 1 no longer holds lock on lockedRecords. That is, it is not required to explicitly call notifyAll() on lockedRecords here.

There are many discussions in the forum about this partiuclar notifyAll() in lock method and most of times it is concluded that it is not required in lock method.
Anton Golovin
Ranch Hand

Joined: Jul 02, 2004
Posts: 476
Originally posted by mike acre:
In reply to Anton


As I see it, every method that reads or writes to the file must be synchronised.

A method moves the pointer then reads or writes from that point. This must be guaranteed as one atomic operation. As such synchronising the methods in your file access object does the job perfectly.

So no, you can't have two threads concurrently writing in different, non-overlapping places. They must be queued with the aid of the objects monitor.


I see what you mean. So now there are three locks. I wonder, though, if the locks on the Data class to prevent multiple threads accessing (different) parts of the file at the same time, serve the same purpose as the record-locking mechanism at the Map. Doesn't one obviate the other?

Why lock a record when it will not be corrupted anyway?
[ August 03, 2004: Message edited by: Anton Golovin ]
Dora Gal
Greenhorn

Joined: Jan 03, 2004
Posts: 15
The question is not about the lock() unlock() methods rather about the context when you access the file itself. I mean that when thread A accesses
a part of the file (e.g.for record 1 - from position 256-316) can other threads access the file to manupulate on other records located on other positions?
the synchronization, wait and notify is quite clear to mean...


Thanks, dora
Raj Nagappan
Ranch Hand

Joined: May 26, 2004
Posts: 38


A method moves the pointer then reads or writes from that point. This must be guaranteed as one atomic operation. As such synchronising the methods in your file access object does the job perfectly.

So no, you can't have two threads concurrently writing in different, non-overlapping places. They must be queued with the aid of the objects monitor.


I don't follow you here, I tried a little experiment in which:
1. ten threads are set up
2. each opens their own RandomAccessFile instance on the same physical file
3. each thread seeks to a different location
4. each thread writes a unique string
5. each thread closes the file and terminates

The shared file turns out fine in repeated runs both with and without random sleeps. In this case each RAF has its own file pointer on the file, so (in theory at least) you should be able to have multiple RAFs each running over the same physical file and not colliding, in the same way that you can have multiple iterators on a single collection object.

Queuing accesses so that they are all serial is tantamount to locking the entire database for the duration of the access.

Correct me if I'm wrong here.
Raj.


Raj Nagappan<br />SCJP, SCJD, PhD
Robert Konigsberg
Ranch Hand

Joined: Jun 23, 2004
Posts: 172
Dora,


Suppose the thread A is reading/updating record 1. Can other threads read/update record 2 at the same time?

Has anyone actually answered this? Here's what I think:

BUT NOTE: This is based on the assumption that your update() method signature looks like this (in some order):

public void update(int recno, String[] params, long cookie);

If thread N wants to update record n, it must get a lock cookie from lock(recno).

i.e.


With that in mind,

If thread A is reading record n, thread B may read record n.
If thread A is reading record n, thread B may update record n*.
If thread A is updating record n, thread B may read record n.
If thread A is updating record n*, thread B may read record n.

*: This means that the thread can get a lock, and summarily perform an update.

Note: As long as the read() and update() methods are synchronized on the same object (ie data object) then while A is reading n, B can't perform the update, which ensures your safety.

Good?


SCJP 1.4 (91%)<br />SCJD 1.4 (376/400, 94%)
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: synchronization- help me i am re-re-reimplementing