Hello, I created a new issue (https://issues.apache.org/jira/browse/CLEREZZA-431) 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 access." 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? Best, Daniel
