file locking

[Bruintje Beer]

Hi,

I have a server which has a class that updates a flat file. There are many
client who access the server. My question is how can I lock the data file so
that each client writes its data to the file without corrupting the data
from the other clients.

I use java 6

mark

 

[Martin Gregorie]

Hi,

I have a server which has a class that updates a flat file. There are many
client who access the server. My question is how can I lock the data file so
that each client writes its data to the file without corrupting the data
from the other clients.

Make the clients pass the data to a single server instance as discrete
messages. Each message should contain a complete, self-consistent piece
of data. The server should queue input in arrival order. If the data
rate is high enough it can use several threads to accept messages from
clients. However, it must use a single thread to remove messages from
the front of the queue and write them to the file. This mechanism
guarantees that no corruption can occur and is OS agnostic (i.e.
unaffected by the locking mechanisms used by and OS.

I can see possible problems if the data value is high and if there's a
mismatch between the way data arrives at the clients and their ability
to pass it on in correctly assembled chunks. HOWEVER, until you tell us
about:
- the number of clients
- the data arrival pattern at a client
- the relationship between incoming data and how it is to be recorded
- the data arrival rate and volume
- if the total data arrival rate can exceed the file writing rate
- if the file is read-write or write-only.

its not possible to give more specific advice.

I use java 6

It doesn't matter whether the clients and server are written in COBOL, C
or some version of Java; the design constraints are the same.

 

[Bjorn Borud]

[Martin Gregorie <[email protected]>]
|
| its not possible to give more specific advice.

how about the lock() method in java.nio.channels.FileChannel? I would
assume that this is implemented by means of flock(2) on most UNIX
systems and whatever underlying mechanism other operating systems
offer on other platforms? If it does what I think it does, it should
be useable to do locking on files, then within the same JVM you would
need to use further concurrency mechanisms to ensure thread-safety?

-Bjørn

 

[Knute Johnson]

Hi,

I have a server which has a class that updates a flat file. There are many
client who access the server. My question is how can I lock the data file so
that each client writes its data to the file without corrupting the data
from the other clients.

I use java 6

mark

How about synchronizing the writes?

 

[Martin Gregorie]

[Martin Gregorie <[email protected]>]
|
| its not possible to give more specific advice.

how about the lock() method in java.nio.channels.FileChannel? I would
assume that this is implemented by means of flock(2) on most UNIX
systems and whatever underlying mechanism other operating systems
offer on other platforms? If it does what I think it does, it should
be useable to do locking on files, then within the same JVM you would
need to use further concurrency mechanisms to ensure thread-safety?

I'd be hesitant to suggest using a locking mechanism without knowing a
lot more about the application. Locking may cause more problems for both
performance and program logic (dealing with lock collisions) than it
solves. Locking offers no help at all for data interleaving or strict
arrival order recording; the latter can be corrupted by lock collisions.

I suggested using a queuing mechanism that feeds a single writer process
because this approach side-steps all the above problems provided only
that it operates fast enough to keep up with the incoming data. However,
we don't know if this is a potential problem since the OP has provided
no information about message sizes and arrival rates.

 

[Bjorn Borud]

[Martin Gregorie <[email protected]>]
|
| I'd be hesitant to suggest using a locking mechanism without knowing a
| lot more about the application.

my response was more of a complement to what you had already answered.
(if people need to ask about these things you don't need to get your
hopes up anyway).

-Bjørn