It seems that one of the major stumbling blocks in building Jena based applications is that iterators is found in the iterator documentation: “The behavior of an iterator is unspecified if the underlying collection is modified while the iteration is in progress in any way other than by calling this [remove()] method.” For Jena applications this means that updates to the underlying graph are prohibited while an iterator is in operation. Iterators are commonly used in query operations.
One work around for this has been to create a copy of the results of a query operation into a local collection and then iterate across that. The net result of this work around is excessive consumption of resources to store the data in flight as it is being iterated over. A second work around has been to use read and write locks and/or transactions to prohibit writing to a graph while the graph is being queried. This solution works well when the number of updates to the graph is small in comparison to the number of queries. When the number of updates increases the data store effectively becomes single threaded. I propose a third work around, a new class of Collection, be considered. I call this a quantum collection as the items in the collection do not exist until they are examined. Conceptually, the collection is defined in terms of constraints on the objects within it. The iterator simply retrieves one of the objects and presents it. Since the collection does not exist in the classical sense there is no modification of the collection – save for the modification of the constraints that define it. In a Java implementation of the Iterator interface on such a collection makes the following contract: hasNext(): Locates an element in the collection to return and returns true if one was found, false otherwise. This method identifies the element as part of the collection. The iterator guarantees that the element was in the collection when the collection was examined. It makes no guarantees that the element is still in the collection or even that the collection contains any elements at all. next(): returns the element located by hasNext() or throws a NoSuchElementException if there are no more elements. If hasNext() was not called, next will call hasNext() to locate the object or determine that none exists. remove(): not implemented always throws UnsupportedOperationException Notice that the collection makes no assumptions about the order or uniqueness of the objects presented by the iterator. The iterator may be constructed so as to return unique objects, or the constraint on the collection may introduce ordering or uniqueness. I believe that such a collection and set of iterators would make streaming queries of large data sets much easier and faster. The trade off is that items that are added or removed over the course of the iteration may or may not be included in the iterator. That is, the number of elements returned by the iterator is indeterminate until all elements have been returned. Thoughts? Claude Warren -- I like: Like Like - The likeliest place on the web<http://like-like.xenei.com> Identity: https://www.identify.nu/[email protected] LinkedIn: http://www.linkedin.com/in/claudewarren
