I'm using Postmodern to query and update a table in a database. The
application is networked and threaded, and in the past we've had
issues where we get compilation style warnings at run time, and even
errors which pop up the debugger. These issues arose when we began
flowing client traffic to our application, and I thought that they
might be because of some race condition in Postmodern's internals when
it starts doing MOP operations on our class which has had
(:metaclass dao-class) added to its class definition.
Because I suspected a race condition--that multiple threads might be
trying to instantiate the MOP stuff around our database accessor class
at once--I worked around it by having our startup procedure do a
single database access before allowing any client traffic in. That
seemed to help things for a while, but this morning I was using the
profiler to instrument our code. When I ran the program, and at a
point where only that one retrieval should've been running, it popped
up with an error in the debugger.
I'm using postmodern-20120520-git as loaded through Quicklisp, on SBCL
1.0.57. The issues have arisen on a variety of x86 hardware, both 32-
and 64-bits.
Here's the defclass for the table in question:
(defclass device ()
((device-uid :col-type integer :initarg :device-uid :accessor device-uid)
(macaddress :col-type string :accessor device-macaddress)
(status :col-type string :accessor device-status)
(state :col-type string :initarg :state :accessor device-state)
(nature :col-type string :accessor device-nature)
(client-uid :col-type integer :accessor device-client-uid)
(user-uid :col-type integer :accessor device-user-uid))
(:metaclass dao-class)
(:keys device-uid))
and here's the function which we call to prime the pump at the start
of program execution:
(defun get-device-object-by-device-uid (device-uid)
(with-connection *db-parameters*
(log-message :device-dao-bug "In get-device-object-by-device-uid,
device-uid = ~A" device-uid)
(let ((result (query (:select '* :from 'device :where (:= 'device-uid
device-uid)) (:dao device))))
(log-message :device-dao-bug "Finished query in
get-device-object-by-device-uid.")
(if result
(car result)
nil))))
The error I got this morning was:
POSTMODERN:DAO-EXISTS-P already names an ordinary function or a macro.
[Condition of type SB-INT:SIMPLE-PROGRAM-ERROR]
Restarts:
0: [CONTINUE] Replace the function binding
1: [*ABORT] Return to SLIME's top level.
2: [ABORT] Abort thread (#<THREAD "repl-thread" RUNNING {1003E48113}>)
Backtrace:
0: (ENSURE-GENERIC-FUNCTION POSTMODERN:DAO-EXISTS-P)
1: (SB-PCL::REAL-ADD-NAMED-METHOD POSTMODERN:DAO-EXISTS-P NIL
(#<POSTMODERN:DAO-CLASS PROJECT-PACKAGENAME:DEVICE>) (POSTMODERN::OBJECT)
#<unavailable &REST argument>)
2: (SB-PCL::LOAD-DEFMETHOD-INTERNAL ..)
3: ((LAMBDA ()))
4: ((LAMBDA (SB-INT:&MORE SB-PROFILE::ARG-CONTEXT SB-PROFILE::ARG-COUNT) :IN
SB-PROFILE::PROFILE-ENCAPSULATION-LAMBDAS) #<unavailable &MORE argument>)
5: ((LAMBDA (SB-INT:&MORE SB-PROFILE::ARG-CONTEXT SB-PROFILE::ARG-COUNT) :IN
SB-PROFILE::PROFILE-ENCAPSULATION-LAMBDAS) #<unavailable &MORE argument>)
6: ((SB-PCL::EMF SB-MOP:FINALIZE-INHERITANCE) #<unavailable argument>
#<unavailable argument> #<POSTMODERN:DAO-CLASS PROJECT-PACKAGENAME:DEVICE>)
7: (PROJECT-PACKAGENAME::GET-DEVICE-OBJECT-BY-DEVICE-UID 1)
Earlier, when we were allowing multiple threads to access this object
at the same time, we got output like this (all of the following is output from
one session):
debugger invoked on a UNBOUND-SLOT in thread
#<THREAD "message handler2" RUNNING {1004843BE3}>:
The slot POSTMODERN::COLUMN-MAP is unbound in the object
#<POSTMODERN:DAO-CLASS
PROJECT-PACKAGENAME:DEVICE>.
STYLE-WARNING:
redefining POSTMODERN:DAO-EXISTS-P (#<POSTMODERN:DAO-CLASS
PROJECT-PACKAGENAME:DEVICE>) in
DEFMETHOD
STYLE-WARNING:
redefining POSTMODERN:UPDATE-DAO (#<POSTMODERN:DAO-CLASS
PROJECT-PACKAGENAME:DEVICE>) in
DEFMETHOD
STYLE-WARNING:
redefining POSTMODERN:DELETE-DAO (#<POSTMODERN:DAO-CLASS
PROJECT-PACKAGENAME:DEVICE>) in
DEFMETHOD
STYLE-WARNING:
redefining POSTMODERN:GET-DAO (#<SB-MOP:EQL-SPECIALIZER
{100C80AFB3}>) in DEFMETHOD
STYLE-WARNING:
redefining POSTMODERN:INSERT-DAO (#<POSTMODERN:DAO-CLASS
PROJECT-PACKAGENAME:DEVICE>) in
DEFMETHOD
STYLE-WARNING:
redefining POSTMODERN::FETCH-DEFAULTS (#<POSTMODERN:DAO-CLASS
PROJECT-PACKAGENAME:DEVICE>) in
DEFMETHOD
STYLE-WARNING:
redefining SHARED-INITIALIZE :AFTER (#<POSTMODERN:DAO-CLASS
PROJECT-PACKAGENAME:DEVICE>
#<BUILT-IN-CLASS T>) in DEFMETHOD
STYLE-WARNING:
redefining POSTMODERN:DAO-EXISTS-P (#<POSTMODERN:DAO-CLASS
PROJECT-PACKAGENAME:DEVICE>) in
DEFMETHOD
STYLE-WARNING:
redefining POSTMODERN:UPDATE-DAO (#<POSTMODERN:DAO-CLASS
PROJECT-PACKAGENAME:DEVICE>) in
DEFMETHOD
STYLE-WARNING:
redefining POSTMODERN:DELETE-DAO (#<POSTMODERN:DAO-CLASS
PROJECT-PACKAGENAME:DEVICE>) in
DEFMETHOD
STYLE-WARNING:
redefining POSTMODERN:GET-DAO (#<SB-MOP:EQL-SPECIALIZER
{100C80AFB3}>) in DEFMETHOD
STYLE-WARNING:
redefining POSTMODERN:INSERT-DAO (#<POSTMODERN:DAO-CLASS
PROJECT-PACKAGENAME:DEVICE>) in
DEFMETHOD
STYLE-WARNING:
redefining POSTMODERN::FETCH-DEFAULTS (#<POSTMODERN:DAO-CLASS
PROJECT-PACKAGENAME:DEVICE>) in
DEFMETHOD
STYLE-WARNING:
redefining SHARED-INITIALIZE :AFTER (#<POSTMODERN:DAO-CLASS
PROJECT-PACKAGENAME:DEVICE>
#<BUILT-IN-CLASS T>) in DEFMETHOD
STYLE-WARNING:
redefining POSTMODERN:DAO-EXISTS-P (#<POSTMODERN:DAO-CLASS
PROJECT-PACKAGENAME:DEVICE>) in
DEFMETHOD
STYLE-WARNING:
redefining POSTMODERN:UPDATE-DAO (#<POSTMODERN:DAO-CLASS
PROJECT-PACKAGENAME:DEVICE>) in
DEFMETHOD
STYLE-WARNING:
redefining POSTMODERN:DELETE-DAO (#<POSTMODERN:DAO-CLASS
PROJECT-PACKAGENAME:DEVICE>) in
DEFMETHOD
STYLE-WARNING:
redefining POSTMODERN:GET-DAO (#<SB-MOP:EQL-SPECIALIZER
{100C80AFB3}>) in DEFMETHOD
STYLE-WARNING:
redefining POSTMODERN:INSERT-DAO (#<POSTMODERN:DAO-CLASS
PROJECT-PACKAGENAME:DEVICE>) in
DEFMETHOD
STYLE-WARNING:
redefining POSTMODERN::FETCH-DEFAULTS (#<POSTMODERN:DAO-CLASS
PROJECT-PACKAGENAME:DEVICE>) in
DEFMETHOD
STYLE-WARNING:
redefining SHARED-INITIALIZE :AFTER (#<POSTMODERN:DAO-CLASS
PROJECT-PACKAGENAME:DEVICE>
#<BUILT-IN-CLASS T>) in DEFMETHOD
For the time being, we're planning to work around this by avoiding the
use of the dao-class metaclass; we'll write our database queries to
return lists or alists, and we'll write update operations directly as
SQL or S-SQL queries instead of using update-dao. If there's a way to
address this problem and continue using the dao-class metaclass,
though, we'd rather do that.
Any advice would be most welcome.
Keith Browne
