Gemstone/S concurrency model and multi-core support?

Hi, I was wondering, what type of concurrency model(s) Gemstone/S support?  STM?  Actor?  Also, can Gemstone/S scale based on the number of cores and is this something easy to configure?

Conrad,

Each gem has "shared view" of the object graph. Changes to the object graph are accumulated while a gem is "in transaction". When a gem performs a "commit transaction", the accumulated changes are merged into the "latest view" of the object graph. If an object in the gem's "dirty list" was changed by a different gem, then the "commit transaction" fails with a "commit conflict" and the commit fails. There are a variety of strategies that can be used to resolve commit conflicts.

With this model, the object graph is guaranteed to be "physically consistent" as conflicts are not allowed. Logical inconsistencies can creep in, but again there are a variety of strategies that can be used to minimize the chances for logical inconsistencies.

Each gem can run on a separate core or even another machine. So scaling is done by running multiple gems.

James Foster has but together a number of short videos[1] on GemStone/S and a number of then relate to your questions.

Dale

[1] http://gemstonesoup.wordpress.com/2010/02/11/gemstone-101-short-features/

----- Original Message -----
| From: "Conrad Taylor" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Saturday, June 11, 2011 5:18:01 PM
| Subject: [GS/SS Beta] Gemstone/S concurrency model and multi-core support?
|
| Hi, I was wondering, what type of concurrency model(s) Gemstone/S
| support? STM? Actor? Also, can Gemstone/S scale based on the number
| of cores and is this something easy to configure?
|
|
|
| Thanks in advance,
|
|
| -Conrad
|
|
|
|
|
|
|
|
|
|
|
|

On Wed, Jun 15, 2011 at 10:11 AM, Dale Henrichs <[hidden email]> wrote: