All SQL repository operations are performed using the current JTA transaction, if one exists. When your application calls the Repository updateItem() methods, for example, your changes become visible to subsequent getItem() calls made in that transaction only. When the JTA transaction is committed, the repository item changes (made with, for example, updateItem()) 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 will be committed to the database when the call returns.

Here are two examples:

If no transaction exists:

Using the updateItem method:

Generally, you will 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 will have the new property value available to them.

You can configure the ATG platform to send repository item cache invalidation messages to other remote ATG servers. If you set the cache mode to distributed mode for an item descriptor, then cache invalidation message will be set. Also, if you set the cache mode to locked mode for an item descriptor, then when a server gives up ownership of the lock, it also invalidates the cache. See the SQL Repository Caching chapter.

The SQL repository implements transaction isolation. The first time the item is accessed in a particular transaction, either through the getItem() call, or the first attempt to call getPropertyValue() in an item which was retrieved in a different transaction, we guarantee that it is up to date at that time. If the item is changed by another transaction while this transaction is in progress, we don’t see those changes until a new transaction is started.

By default, a transaction will be created and committed for each method call. This is generally not the most efficient way to handle repository item updates. It is generally most efficient to ensure that all of the method calls in creating or updating a repository item are performed in a single transaction. The ATG platform offers several different techniques for transaction demarcation that you can use to group repository method calls into a single transaction. These are described in detail in the Transaction Management chapter in the ATG Programming Guide.

One option is to use the Transaction servlet bean to explicitly create a transaction in a page. This servlet bean is described in Appendix B: ATG Servlet Beans in the ATG Page Developer's Guide. For example, the following uses the current transaction, if any exists. If there is no current transaction, then one is created before calling the output open parameter, then committed at the end of the droplet:

<droplet bean="/atg/dynamo/transaction/droplet/Transaction">
  <param name="transAttribute" value="required">
  <oparam name="output">

    ... do repository item work ...

  </oparam>
</droplet>

You can also use the JTA (Java Transaction APIs) to explicitly manage the transaction. For example, you might explicitly create a transaction around a repository item creation or update like this:

TransactionManager tm = ...
TransactionDemarcation td = new TransactionDemarcation ();
try {
  try {
    td.begin (tm);

    ... do repository item work ...
  }
  finally {
    td.end ();
  }
}
catch (TransactionDemarcationException exc) {
  ... handle the exception ...
}

If you are writing a FormHandler component, you can simply extend the class atg.droplet.TransactionalFormHandler. This FormHandler automatically wraps a transaction around all property get method calls called from a page and another transaction around all property set or handle method calls made from a page. See the Working with Forms and Form Handlers chapter of the ATG Programming Guide for more information.

 
loading table of contents...