• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

synchronization- help me i am re-re-reimplementing

 
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
the question in a simpler way...

do you have


or

 
Ranch Hand
Posts: 531
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Ranch Hand
Posts: 197
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 697
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 531
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator



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.
 
Ranch Hand
Posts: 172
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
What do you have to say for yourself? Hmmm? Anything? And you call yourself a tiny ad.
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic