[elephant-devel] Re: Getting count of the number of persistent objectsof a particular class

[Ian Eslick]

If the directions are not clear, I apologize, but it is good practice  
to always call (make-instance 'persistent-class) from within a  
transaction to ensure ACID properties for object creation.  This is  
not terribly important for interactive, non-critical uses of the DB.   
But in multi-threaded environments it becomes important to ensure you  
don't corrupt the database in odd ways.

During instance creation the following subtasks are guaranteed to be  
in a transaction (i.e. wrapped in an ensure-transaction call):
- initialization of persistent slot values
- class index update for indexed classes

Any other before/after/around methods on initialize-instance or shared- 
initialize are not wrapped in a transaction.  The bottom line is that  
to ensure that these methods plus the two above subtasks are  
transactional, be sure that make-instance is called within a  
transaction.

If you don't, you will lose Atomicity and Consistency for object  
creation of indexed instances or instances with any other persistent  
side effects in after/before/around methods.

Why don't we put this in a transaction by default?  In part this is  
tied up in the recent discussions about initialization vs.  
reinitialization during serialization, part is tied up in not creating  
a false sense of security leading to problems when you engage in  
natural uses of the MOP, for instance (defun initialize- 
instance :after ((obj my-class) ...)), and part not having been fully  
thought through yet.

Ian

On Jan 21, 2008, at 10:29 AM, Joubert Nel wrote:

>
> On Mon, 2008-01-21 at 09:54 -0500, Ian Eslick wrote:
>> In general, instance initialization should always happen inside a
>> transaction.  This will catch any updates you do to indices or other
>> variables.
>>
>> The instance initialization code in Elephant only forces transactions
>> for subsets of initialization that use cursors, and which under BDB
>> would lead to deadlocks or other errors.  This allows developers
>> flexibility in breaking up large initialization transactions but the
>> consequence is that the set of side effects of a default call to  
>> make-
>> instance are not atomic unless wrapped in a transaction.
>
> OK, so if I add an initialize-instance :after method, for example,  
> then
> a call to (make-instance 'persistent-class) must now be called from
> within a transaction to ensure atomicity?
>
>
> Joubert
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel