??>> changing isolation level is dead simple, but it requires dealing with
??>> consequences. this was pretty hard for application i'm working with,
??>> so i had to make extensions like retry-cleanup-fn.
LPP> Can you elaborate on that? Seems complicated...
retry-cleanup-fn? it's actually pretty simple -- it gives application
ability to hook it's code just before restarting transaction.
this way application can do custom cleanup.
for example, i'm working with UCW. it has built-in retry restart implemented
this way:
(try-again ()
:report "Restart the HANDLE-REQUEST protocol at the server level"
(clear-response response)
(handle-request server request response))
it clears what application have generated so far and starts handling request
over.
i can do this cleanup via retry-cleanup-fn:
(ele:with-transaction (:retry-cleanup-fn (lambda (&rest ignored)
(ucw::clear-response response)))
..code..)
this will work fine if transaction is around handle-request.
alternatively, i can use retry-cleanup-fn to implement custom retry
strategy -- i.e. call try-again restart:
(ele:with-transaction (:retry-cleanup-fn (lambda (&rest ignored)
(invoke-restart 'ucw::try-again)))
..code..)
we'll lose retry counting ability because there will be non-local control
transfer into UCW's retry implementation, but it should otherwise work fine
if with-transaction is inside handle-request.
also this can be used to do logging:
(ele:with-transaction
(:retry-cleanup-fn
(lambda (condition sc)
(declare (ignore sc))
(lg.warn "got database error: ~a, retrying transaction~%"
condition)
(ucw::clear-response (context.response *context*))))
...)
this might help analysing performance problems
so this appears to be quite a useful extension -- it allows us to integrated
elephant's transaction handling into relatively complex applications not
specially designed for transaction restarts.
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
