incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Spicar <>
Subject RDFList should not write in its constructor (Clerezza-431)
Date Tue, 22 Feb 2011 11:56:29 GMT

I created a new issue (
but I would like to discuss this problem so everyone is aware of it. Here is
the description copied from the issue:

"The implementation of RdfList in the rdf.utils project performs a write in
its constructor when creating an empty RdfList.

This is dangerous because when the underlying graph is a
LockableMGraphWrapper it tries to get a write lock on the graph before
adding. If the creation of the list happens inside a read lock on the same
graph this will create a deadlock. It requires a lot of knowledge of the
implementation to be aware of these side-effects.

It may be better for users of RdflList if no such unexpected locks are set.
The write access happens, because for an empty list, the triple
"listResource owl:sameAs rdf:Nil" is added to the underlying graph. This is
correct but not necessary. The suggestion is that the presence of an
rdf:first property is used to determine whether the list is empty or not. We
can provide a static method for the user to create an empty list with the
owl:sameAs rdf:Nil triple if a user desires to do so and is aware of the
side effects. In the add and remove methods the owl:sameAs rdf:Nil triple
can still be removed/added as these operations clearly require write

We feel that this issue needs to be addressed because we have faced quite
serious and hard to debug problems because of the current implementation.
The reason is that there are several situations where you may not be aware
of the potential deadlocks. One is that a user may not be aware that the
graph is actually a LockableMGraphWrapper and that is performs locking. But
this is quite common when acquiring the graph with TcManager.

Another issue is that the user may not be aware that the graph doesn't
contain the list he is looking for and therefore doesn't expect the
owl:sameAs rdf:Nil triple to be added. This can occur when blank nodes are
used and the blank node used as listResource is not the same instance as the
one the user expects. Or due to some error situation the graph or the
listResource may be different from the expected. The problem here is that
the resulting deadlock may be very confusing and hard to pin down without
knowing about this implementation detail.

What are you thinking?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message