The with-transaction macro passes keyword arguments to the controller- create-transaction backend fn which you may also call directly if you want to do something more sophisticated than wrap body code in with- transaction.

Some examples for BDB:

dirty-read - Read written but uncommitted values. For example if you're walking over a btree and you don't want to restart because someone inserted a value on a previously read or just about to be read value. Also saves computation time and txn memory.

txn-nosync - Do not wait while for synchronization to disk. Can have a noticable performance benefit but it means that the transaction is not durable - future code may assume it committed, but if the database crashes that transaction may be unwound.

txn-nowait - do not block on locks (return error DB_LOCK_NOTGRANTED immediately)

Ian

On Mar 16, 2008, at 11:48 AM, Alex Mizrahi wrote:

??>>>>> * handle pg error 23505 (duplicate primary key race condition)
??>>
??>> i guess race condition in plpgsql should be handled by switching to
??>> serializable transaction isolation level. (that's what i'm doing)

LPP> I don't quite see how the two of them go together.
LPP> The isolation guarantee level should be settable by the user
LPP> and the PM backend should work in any case, shouldn't it?

why would we need anything other than best isolation level?
people might prefer "read commited" because it yields no retries, but we
need retries anyway (in case of deadlock or duplicate pk), so i see no
reason.

i'm pretty sure there can be other race conditions and best way to avoid
them is to use serializable isolation level.
also Ian says that serializable is default level in BDB backend, i think it
would be good if two backends will be consistent on this matter.



_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel

_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel

Reply via email to