of the differentiating factors between it and most object relational mapping tools,
which generally only allow single record changes.
Handling concurrent updates
One thing that i BATIS does not currently implement is any sort of record locking
to manage concurrent modifications to the same data. You can use one of several
techniques to handle concurrent updates, such as using a timestamp or version
number on rows in the database. For example, if you have an account table
CREATE TABLE account (
accountid serial NOT NULL,
CONSTRAINT account_pkey PRIMARY KEY (accountid)
you can increment the version column in the record when you update it, and use
both the accountId and version fields in the where clause of the update statement.
When the update runs, if the record that is being updated has not been changed
by another user, then the update will be successful because the version number
has not been changed, and the mapped statement will return the expected record
count of one. If it returns zero, and no exception is thrown, then you know that
someone else updated the data since you read it from the database. How you pro-
ceed in your application once you have this information is up to you.
Updating or deleting child records
It is not unusual for an object model to include components that also contain
child objects. For example, an Order object may contain a list or array of Order-
Item objects that represent the items that were ordered.
Because the i BATIS framework is primarily a SQL mapping tool, it does not
manage these sorts of relationships when updating the database. As a result, this
functionality is something that must be handled in the data layer of your applica-
tion rather than in i BATIS . The code to accomplish this is pretty simple: