All SQL repository operations are performed with the current JTA transaction, if one exists. For example, when an application calls the Repository updateItem() methods, for example, changes are immediately visible only to subsequent getItem() calls that are made in that transaction. When the JTA transaction is committed, the repository item changes are committed to the database.

If you do not have a JTA transaction in place, each SQL repository operation that affects the state of a repository item creates and commits a transaction around the operation. Thus, a setPropertyValue call by itself with no JTA transaction in place is committed to the database when the call returns.

Here are two examples:

If no transaction exists:

Using the updateItem method:

Generally, you want to call updateItem explicitly. This ensures that if you perform any queries between the change made in the setPropertyValue call and the commitment of the transaction, those queries have the new property value available to them.

Distributed cache invalidation

You can configure the Oracle ATG Web Commerce platform to send repository item cache invalidation messages to other remote Oracle ATG Web Commerce servers. If you set an item descriptor to one of several Distributed Caching Modes, a cache invalidation message is sent to other Oracle ATG Web Commerce servers. You can also set an item descriptor to Locked Caching mode; when a server gives up ownership of the lock, it also invalidates the cache. For more information see the SQL Repository Caching chapter.

Transaction isolation

The SQL repository implements transaction isolation. The first time an item is accessed in a transaction—through getItem(), or the first attempt to call getPropertyValue() on an item that was retrieved in a different transaction—it is guaranteed to be up to date at that time. If another transaction changes the item while this transaction is in progress, those changes are visible only to a new transaction.