[rules-users] does WorkingMemory.iterator support remove()?

[Michael Anstis]

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 at 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 at lists.jboss.org
> [mailto:rules-users-bounces at lists.jboss.org <rules-users-bounces at 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 at codehaus.org> <mproctor at 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 at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users
>
>
>       _______________________________________________
> rules-users mailing listrules-users at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users
>
>     _______________________________________________
> rules-users mailing listrules-users at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users
>
> ------------------------------
>
> _______________________________________________
> rules-users mailing listrules-users at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20071005/dfede675/attachment.html