Hidden Concepts of ATG Repository- Part 3

2. Last Modified Date and Version Properties

Last Modified Date: Last Modified Date is used at item level to identify the items that are being changed from given timestamp.

                <item-descriptor ......... last-modified-property="lastModDate">
                           <attribute name="updateLastModified" value="true"/>
                      <table ...>
                            <property name="lastModDate" data-type="timestamp"/>
                      </table>
                 </item-descriptor>

The five important must points to set the last modified date are

• data-type of  last-modified-property has to be "date" or "timestamp".
• Property should be persistent and single valued.
• Property should be placed in Primary or Auxillary table.
• item descriptor should contain last-modified-property.
• Attribute "updateLastModified" should be set to true.

Additional Safety: 

• Column in DataBase can have default value to set to sysdate, so that, in case of insertion of Null, DataBase Updates the row with system date(current date). 
• Hide the Property in ACC and BCC by adding hidden="true".

Version Property: Locking System can be obtained by using the version property at item level. The data-type of property must be "int" or "long" and column must be appropriate to support int or long.

           <item-descriptor name="user" version-property="version">
                    <table name="my_user" id-column-names="id"/>
                             <property name="version" data-type="int"/>
                    </table>
           </item-descriptor>  

• The value of the version property is incremented every time the item is updated. Its value starts as 0 when the item is created, is set to 1 when the item is added, and is incremented in each subsequent update. 
• If you try to update the item from a transaction whose version does not match the current version number in the database, a ConcurrentUpdateException is thrown to abort that update.

Scneario copied from ATG Docs.
1. Dynamo1 reads a repository item for update. It obtains the item’s version property,
which has a value of 2.

2. Dynamo2 reads the same repository item for update. Because Dynamo1 has not yet
committed any changes to the item, Dynamo2 gets the same value for the item’s
version property, 2.

3. Dynamo1 updates the repository item. In the course of the update, the value for the
version property in the repository item is checked to see whether it is the same as
what is found in the corresponding database column. In this case, both values are still
2. The update to the repository item is committed, with the version property
incremented by 1, so the value of the version property is now 3.

4. Dynamo2 tries to update the repository item. When the value for the version property
in the repository item is checked to see whether it is the same as what is found in the
corresponding database column, the values do not match. Dynamo2 is holding a value
of 2, while the value of the version property in the database is now 3. Dynamo2 throws
a ConcurrentUpdateException and does not apply the changes in the update.
This can be very useful for simple and distributed caching modes where there is a possibility of
overwriting another Dynamo’s changes.

You can take advantage of optimistic locking in pages that include forms.