[elephant-devel] postmodern btree problem

[Alex Mizrahi]

Looks like that is not one of "usual suspects".. And it is more than 
weird -- key-type slot in pm-btree
has initform, so it is unbound only when one explicitly makes it unbound, 
and I have no idea where
that could be (in theory, we do not do that at all). To debug this you can 
add checks like

(defun check-pm-btree-sane (bt)
  (and (db-postmodern::table-of bt) (slot-boundp bt 
db-postmodern::key-type)))

in places where you read btree from object slots and where you use btree, so 
at
least we'd know if it goes crippled straight from deserialization, or gets 
corrupted somewhere in process.

also it makes sense to investigate nature of this object -- get its oid 
(maybe just descibe it to see if
there is something unusal) and check if there exists table called (format 
nil "tree~a" oid) and
also a record in metatree for this table name.

also it might make sense to instrument function get-cached-instance a bit to 
know whether
crippled pm-btree is recreated or just retrieved from cache. something like:

(defmethod get-cached-instance ((sc store-controller) oid class-name)
  "Get a cached instance, or instantiate!"
  (declare (type store-controller sc)
    (type fixnum oid))
  (let ((obj
  (ele-with-fast-lock ((instance-cache-lock sc))
    (get-cache oid (instance-cache sc)))))

     ;; TRACE
    (when (equal class-name "DB-POSTMODERN::PM-BTREE")
      (if obj (format t "get-cached-instance pm-btree ~a from cache~%" oid)
                 (format t "get-cached-instance pm-btree ~a  recreated~%" 
oid)))

    (if obj obj
 ;; Should get cached since make-instance calls cache-instance
 (recreate-instance-using-class (find-class class-name) :from-oid oid :sc 
sc))))


 ??>>  do you have transactions that are aborted?

 HD> No, I have a single transaction (WITH-TRANSACTION) around my test case,
 HD> and I start with an empty (freshly created) database.  I notice
 HD> however,  that a EXECUTE-TRANSACTION is being run for each persistant
 HD> object I  create within the WITH-TRANSACTION body. 
ELEPHANT:*CURRENT-TRANSACTION*
 HD> doesn't seem to be bound, so the ENSURE-TRANSACTION wrapping the object
 HD> creation is calling EXECUTE-TRANSACTION.

that's ok, actually -- db-postmodern uses its own mechanism to track 
transactions,
so *current-transaction* won't be set, indeed. this ain't harmful and 
shouldn't add significant overhead.
(if you ask me, it is not really good, i'd say it does it this way for 
"historic" reasons)