Question

I am writing a little shop administration software for my uncles fishing shop. It supports multiple clients which access a single database in a local network. I am currently searching for a way to synchronize the access to the database. One solution would be to write a server program which manages the db access. But I have no experience in network programming, so I would like to find an other solution. I came up with the following:

Every entry in the database has a timestamp that informs about the last time it was edited. Before a client edits an entry it reads the timestamp to check whether the entry has been modified by another client. If that is the case, the client does not write to the database but informs the user. The user has to merge his local changes with the modified db entry. The process of reading the timestamp, checking the timestamp and writing to the database would be implemented as a single jdbc transaction.

What do you think, would that work?

Was it helpful?

Solution

For your application, since it seems to be pretty small (reasonable amount of clients, low concurrency, ...), you should use a transaction-aware database (and engine, like MySQL's InnoDB, though it's only an example), and run in SERIALIZABLE transaction isolation. From that point on, you are guaranteed that no two people can update the same thing without knowing, and you'll just have to follow best practices.

Using the timestamps is what is generally called "optimistic" locking. Basically read, and try to write expecting stuff will not chave changed (including the timestamp or version number in the WHERE clause), and it's generally a good thing to do (at least for applications of the scale of yours, apps with lots of clients, high concurrency would suffer this in some sitations)

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top