JGenerator supports datetime stamps, optimistic locking, userNames and pessimistic locking. Together they provide the basis for a complete set of locking strategies to suit all purposes.

• Date Time Stamps
• Optimistic Locking
• User Names
• Pessimistic Locking
  

DateTime Stamps

Datetime stamps can be used to keep objects fresh in memory. When an object is persisted to the database a datetime stamp field records the event on the same row. When an Object is reloaded from the database the objects datetime stamp is checked against that on the database. If the datetime stamp on object is older than that on the database then the object is reloaed from the database. This not only keeps the objects data fresh, but reduces the number of reads from the database client.

By default JGenerator assumes that a column called dateTimeStamp is the datetime stamp. This default can be overidden across the database, by stating in the property file.

dateTimeStamp.column=<propertyName>

The name of the dateTimeStamp column can be changed on per table basis.

<ClassName>.dateTimeStamp.column=<propertyName>

For example if the column name on the Address table is dateTimeLock, then the properties file would state:-

Address.dateTimeStamp.column=dateTimeLock

If there the default behaviour is to have no dateTimeStamp columns across the database this can be stated in the property file as follows :-

dateTimeStamp.column=[true|false]

If there the behaviour is to have no dateTimeStamp on a table this can be stated in the property file as follows :-

<ClassName>.dateTimeStamp.column=[true|false]

Optimistic Locking

Optimistic Locking is when the application takes an optimistic view as to whether anybody else can edit an object at the same time.

Using optimistic locking means that when an object is stored the user can be informed as to whether the object has been updated since they started to loaded it.

An advantage of Optimistic Locking is that if a user decides to leave an Object in the middle of editing an intent (to edit) lock is not left on the object so other people can edit it. A disadvantage of Optimistic Locking is that you never know if somebody else is editing an object at the same time. Optimistic Locking is well suited to internet applications where

A dateTimeStamp column must exist for any table using optimistic locking.

Optimistic Locking is switched off by default. It can be swicthed on for every table using the following: -

optimisticLocking=true

It can be switched on on a per table basis.

<ClassName>.optimisticLocking=[true|false]

For example :-

Address.optimisticLocking=true

User Names

User Names can be used to declare ownership of objects. When an object is persisted to the database the userName field records who owns that record. When the object edited a check can be made to see if that object is owned by anyone. As well as literally using userNames in the userName column foreign keys to user tables could be used to supplement the information.

By default JGenerator assumes that a column called userName is the user name. This default can be overidden across the database, by declaring in the property file.

userName.column=<propertyName>

The name of the userName column can be changed on per table basis.

<ClassName>.userName.column=<propertyName>

For example if the column name on the Address table is ownerName, then the properties file would state:-

Address.userName.column=owner

If there the default behaviour is to have no userName columns across the database this can be stated in the property file as follows :-

userName.column=[true|false]

If there the default behaviour is to have no userName column on a specific table this can be stated in the property file as follows :-

<ClassName>.userName.column=[true|false]

Pessimistic Locking

Pessimistic Locking is when the application takes a pessimistic view as to whether anybody else can edit an object at the same time.

Using pessimistic locking means that when an object is edited a user field records the event on the same row. If somebody else tries to edit the object they must wait until the lock is released. There is still an issue of staleness so datetime stamps are often also used.

An advantage of Pessimistic Locking is that you always know if somebody else is editing an object at the same time. A disadvantage of Pessimistic Locking is that if a user decides to leave an Object in the middle of editing an intent (to edit) lock is left on the object so other people can't edit it.

JBeans Sessions and Homes can retrieved using a Key which is used as the current lock.

A lockColumn must exist for any table using pessimistic locking.

Pessimistic Locking is switched off by default. It can be switched on for every table using the following: -

pessimisticLocking=true

It can be switched on on a per table basis.

<ClassName>.pessimisticocking=[true|false]

For example :-

Address.pessimisticLocking=true

The dateTimeStamp can be used to determine the length of time the object has been locked for, as to whether the lock should be overidden.