If the synchronousInvalidationEvents property is set to true on the repository that is sending an invalidation event, then the thread that modifies the item waits to commit the transaction until a return has been received. This will hold up any other threads that are attempting to either read or modify the same row to ensure that data integrity is maintained.

You can configure ATG to use either synchronous or asynchronous events when it is invalidating components in another JVM. Use of asynchronous events will be significantly faster than use of synchronous events, but leaves open a slight window where stale data can still be seen by another server until the asynchronous event has been received and processed. Typically this time window is very small (on the order of 100 milliseconds or so) and it is unlikely to affect the behavior of your application. Use of synchronous events has the advantage of eliminating this time window, but the disadvantage that it will both slow down your application and, if one application server instance is not quick at responding to the events it receives, it will hold up your other server instance.

By default, ATG is configured to use asynchronous events, but you can enable it to use synchronous events by setting the synchronousInvalidationEvents property of the GSARepository component to true.

 
loading table of contents...