Concurrency Tuning

This page describes what parameters in Domain.xml are there to adapt Slide to your concurrency requirements. Some of these setting may only be available in Slide 2.2

General

Slide's general concurrency parametes are in the configuration section of Domain.xml. They include

These parameters are set using name value pairs. For example to set sequential-mode to fine-grain you would have something similar to this in your Domain.xml

{{{<slide>

...}}}

Store

Store specific parameters are also set in Domain.xml, however they are in the store defintion parts either in the compound parts or inside the specific child stores.

For example to set cache-timeout in your simple store to 100 seconds and make its child node store to defer saves you would have something similar to this in your Domain.xml

{{{<slide>

...}}}

The parameters for compound parent stores mainly effect caching as described in CacheConfiguration, but also have some impact on concurrency. E.g. if a resource is retrieved from caches, the underlying store has no idea of this and thus can not set a read lock. As internal caches feature a lock less isolation similar to read committed, the effective isolation level will be a mixture of this and the one used by the persistent store.

Tx File Store (standard store)

The standard file store uses pessimistic locking to achieve serializable transaction. No real deadlock detection is available, yet, only timeouts. You can set the timeouts:

You can also ask the tx file store not to execute write requests immedeately, but at commit time. While this reduces the amount of write accesses write locks are not immedeately acquired. In combination with deferred read requests due to caching this may weaken the isolation of your transactions:

Memory Store

The memory store is based on a transactional map that uses an optimistic locking scheme similar to Oracle's snapshot isolation. It might fail upon commit. If the repeat-upon-conflict option as been enabled as described above the transaction will be repeated, otherwise it fails. There are no special parameters.

JDBCStore

In the JDBC DB stores you can set the well known ANSI isolation levels:

As caching does not support more than read committed, it is questionable if higher isolation levels make sense. If you choose them you will get some higher isolation which, however, very hard is to define and depends on many parameters.

ConcurrencyIssues (last edited 2009-09-20 22:02:44 by localhost)