The concept of isolation is in general not well understood.
Most programmers seem to expect a kind of "do what I mean" behaviour from the underlying system if ever they are forced to consider such things.
In Transaction terms it is the degree to which the transaction succeeds in isolating its client from both causing an external change of state prior to the transaction commit, and from accessing external data that has been modified since the transaction began.
This is the most common form of isolation. This means that within your transaction, you will be able to access data that has been committed by other transactions since your transaction began. That you will be able to read committed data.
At first this seems quite a reasonable behaviour - mainly because developers don't think too hard about these kind of issues. But if you do think a while, you'll realise that computations and interactions based on a shifting context are not a good idea. Really you want to be able to interact with a consistent view, introducing your own modifications before attempting to commit the modifications to the "real" world.
This form of isolation guarantees that all data accessed will be consistent with when the transaction was begun, and the only updated data retrieved will be that that this transaction has updated.
Most databases offer this level of isolation with a performance warning (if at all).
Cut The Crap Transaction objects by default provide read-committed isolation
but may be fully isolated with most of the underlying Object Managers with a negligable
impact on performance.
>>> from cutthecrap.gpo.client import OMClient;
>>> from cutthecrap.gpo import *;
>>>
>>> om = OMClient("", "/ctc/db/ex1.gpo");
>>> g1 = GPOMap(om);
>>> g1.set("name", "first");
>>> om.remember("test", g1);
>>> t = om.createTransaction();
>>> t.isolate();
>>> g1.set("name", "second");
'first'
>>> g1.get("name");
'second'
>>> t.recall("test").get("name");
'first'