Hello all,
I have a question with regards to the update method of the BaseDAO class
found in the WebPIM application. As it is currently written it would appear
to allow for writes of dirty data. That is to say that if two users read
the same record, lets say company record, and user1 changes the company
field to "XYZ" and User2 changes it to "AAAAA", if user2 commits his record
and then user1 commits his, user2's changes will be lost. No exception is
thrown since the update just does an update where the id is equal to the
value of the id of the crs.getBigDecimal("id") of the current row.
Am I missing something here or is this an issue/bug with the current
implementation? If the update was being applied to the CRS and then the
crs.acceptChanges() method applied, the CRS would handle comparing the
contents of the CRS to the actual db prior to committing the changes, but
since a new connection is obtained and a standard update applied, there is
no support for concurrency. It seems that there either needs to be a
version field on all tables which is included in the update statement of the
prepareUpdateSQL method which does something like below:
UPDATE theTable SET version=<newversion> [and other fields] WHERE
[criteria] AND VERSION=<oldversion>
where <oldversion> is the version is the version from the crs current row,
and
<newversion>=<oldversion>+1.
In this way if two users update the same record of a table at roughly the
same time, the first ones changes will be committed, but the second ones
will generate an error which can be caught and the end user notified of for
corrective action.
Any thoughts on this?
I have modified the BaseDAO to support multiple tables rather then one as it
currently does. This opens up another issue of transactional integrity. If
a crs is created from a join between two or more tables, one needs to start
a transaction to support the individual updates as one unit of work. I
have added methods to support transactions to ensure that if the crs has
data from more then one table that either all changes are committed or none
are.
Any thoughts on this?
Regards,
Todd G. Nist
_______________________________________________
MVC-Programmers mailing list
[EMAIL PROTECTED]
http://www.basebeans.com:8081/mailman/listinfo/mvc-programmers
