Squeak
  links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
Minmizing concurrency in Magma
Last updated at 11:56 pm UTC on 16 January 2006

Minimizing concurrency, the importance of keeping transactions short

If concurrency is defined as the frequency of commit failures, one way to minimize concurrency is to minimize the size and duration of transactions. Long transactions increase concurrency not only by potentially changing more objects, but by allowing more time for "challengers," objects changed by other users, to accumulate. When many users are all running long transactions, it can compound the concurrency problem and, eventually, place undue burden on the Magma server.

Because of the dynamic nature of Magma, frequent crossing of transaction boundaries is also important even if you aren't committing transactions. A simple abort every 30 seconds or so should be sufficient while you have a connected MagmaSession, even if you don't have a transaction. That's because the Magma server keeps track of every object changed by other users, called a "challenger," since you last crossed. As other users continue to commit transactions, their challengers are buffered into a list exclusively for your session. The longer your session waits to cross, the more challengers will accumulate into this list.

When your session finally does cross (via a begin, commit or abort), the entire list of challengers is faulted down over the network and applied in your local image. It is then emptied on the server, freeing memory, and begins to accept new challengers for each transaction committed by other sessions.

Each sessions list of challengers consumes some memory in the Magma server. Magma has functionality to protect the machine its running on from running out of memory by removing the challengers list for any session which accumulates too many. For now, this means the session is terminated and must be reconnected. Later (in a future version of Magma), it will mean a "full refresh" will be required by that session when it finally does cross. The maximum number of challengers to allow is settable when you administrate the repository, and may be customized when connecting an individual sessions.

A future versions of Magma may also include a forked background process that produces timed aborts for you, as long as you're not in a transaction.