ConcurrencyIssues

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

• sequential-mode (default "off") enables internal locking

  • off turns internal locking off

  • write global mutex for write request, i.e. only one request may write at a time

  • full global read/write lock; only one request may write at a time and if so there can be no concurrent read

  • fine-grain local read/write locks; allow for much higher concurrency; details: locksNeeded

    • Caution: There are scenarios where Slide's internal locking can cause distributed (unresolvable) deadlocks. This can be when the DB has more coase grain locks than Slide or when there are other applications accessing the same data as Slide.

• repeat-upon-conflict (default "false") sets if a request should be repeated in case it conflicted with a concurrent one (otherwise it fails)

• max-retry-repeat (default "1") if so, how often

• all-methods-in-transactions (default "false") if enabled not only write, but also read requests are executed inside of transactions; offers better protection, but means more overhead

  • Caution: Write operations will need a transaction, so be sure to have this enabled when using user auto creation

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> 
  <namespace ...>
    ...
    <definition>
      ...
    </definition>
      <configuration>
        <parameter name="sequential-mode">fine-grain</parameter>
      </configuration>
...

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> 
  <namespace ...>
    ...
    <definition>
      <store name="simple">
        <parameter name="cache-timeout">100</parameter>
        <nodestore classname="org.apache.slide.store.txfile.TxXMLFileDescriptorsStore">
          <parameter name="defer-saving">true</parameter>
          ...
      </nodestore>
        ...
      </store>
     
      ...
    </definition>
...

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:

• timeout (default 5 seconds)

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:

• defer-saving (default "false")

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:

• isolation (default READ_COMMITTED)

  • READ_UNCOMMITTED

  • READ_COMMITTED

  • REPEATABLE_READ

  • SERIALIZABLE

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.