Excuse me if this would be best posted to the developer list...
...but let me undertstand: The Fact table maintained for a WorkingMemory is
not thread safe(?); however WorkingMemories are thread safe - suggesting
Shadow Facts and (excuse my vague terminolgy) Node Memories are the thread
safe aspect of working memories - the Fact table containing references to
the original inserted objects not the Shadows. So if a Fact is removed using
my "unsafe" code it will cause Shadow Facts to become disconnected from
their original non-shadowed Fact? Would using ThreadLocal storage for the
Fact table (together with node memories and shadow facts) mean a complete
thread-safe Drools? I don't mean this to become a tutorial in either Drools
threading or general java thread safety!! (I don't think there's a category
on the "how to have your emails ignored" listing for this). I just want to
increase my awareness of (Drools) threading issues... and this proves a good
example.
On 05/10/2007, Mark Proctor <mproctor(a)codehaus.org> wrote:
Anstis, Michael (M.) wrote:
Wouldn't the best approach be to get the FactHandles iterator and retact
them from working memory rather than removing them through the iterator?
Iterator itr = wm.iterateFactHandles();
While(itr.next()) {
FactHandle h = itr.next();
wm.retract(h);
}
This would ensure truth maintenance is preserved.
Actually I'm not sure that would be safe.... the objects and the handles
are in the same hashtable. Those internal data structures where built for
performance and lightweightness, not thread safeness and mutability. If you
actually look we have an internal, fast, iterator which we simple adapt to a
slower java.util.Iterator. At the moment none of our iterators are thread
safe, but I do see a valid use case here, we will have to think on it for
the next major release - cleam implementation patch welcome with unit tests
:) I'm less concerned about the iterator adapter performance, but I cannot
compromise on the performance of our internal iterators.
public static class HashTableIterator
implements
Iterator {
private static final long serialVersionUID = 400L;
private AbstractHashTable hashTable;
private Entry[] table;
private int row;
private int length;
private Entry entry;
public HashTableIterator(final AbstractHashTable hashTable) {
this.hashTable = hashTable;
}
/* (non-Javadoc)
* @see org.drools.util.Iterator#next()
*/
public Object next() {
if ( this.entry == null ) {
// keep skipping rows until we come to the end, or find
one that is populated
while ( this.entry == null ) {
this.row++;
if ( this.row == this.length ) {
return null;
}
this.entry = this.table[this.row];
}
} else {
this.entry = this.entry.getNext();
if ( this.entry == null ) {
this.entry = (Entry) next();
}
}
return this.entry;
}
/* (non-Javadoc)
* @see org.drools.util.Iterator#reset()
*/
public void reset() {
this.table = this.hashTable.getTable();
this.length = this.table.length;
this.row = -1;
this.entry = null;
}
}
-----Original Message-----
From: rules-users-bounces(a)lists.jboss.org
[mailto:rules-users-bounces@lists.jboss.org <rules-users-bounces(a)lists.jboss.org>]
On Behalf Of Godmar Back
Sent: 05 October 2007 16:40
To: Rules Users List
Subject: Re: [rules-users] does WorkingMemory.iterator support remove()?
Thanks - consider supporting it for efficiency. (Otherwise, removing a
set of facts from working memory requires a temporary container to
hold the facts to be removed.)
- Godmar
On 10/5/07, Mark Proctor <mproctor(a)codehaus.org> <mproctor(a)codehaus.org>
wrote:
Godmar Back wrote:
Does the iterator returned by WorkingMemory.iterator support remove()?
I checked the javadoc and the Drools manual, but may have missed it.
If you try it you'll get an exception thrown
"UnsupportedOperationException"
http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-core/src/main/jav
a/org/drools/util/JavaIteratorAdapter.java
Please answer and augment documentation.
- Godmar
_______________________________________________
rules-users mailing
listrules-users@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing
listrules-users@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing
listrules-users@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users
------------------------------
_______________________________________________
rules-users mailing
listrules-users@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users