[rules-users] does WorkingMemory.iterator support remove()?
Mark Proctor
mproctor at codehaus.org
Fri Oct 5 22:39:00 EDT 2007
The WM is thread safe, on all insert/update/delete we apply a lock
making sure that not more than one operation can happen. However we do
not apply this lock when the iteraters are used externally via users -
so while iterating any working memroy actions should be avoided. For the
minute I think you would have to do it in two stages, iterate and store
the objects you wish to change in a list. Then iterate that list and
remove/modiy them via the normal working memory api. You can't remove a
fact via unsafe code, the workingmemory.retract(...) is thread safe.
Mark
The iterators do not have "remove" so cannot damage the internal "assert
table" but if you change an underlying object and don't notify
Michael Anstis wrote:
> 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
> <mailto: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>
>> [mailto: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> <mailto: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
>> <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 list
>>>> rules-users at lists.jboss.org <mailto:rules-users at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users at lists.jboss.org <mailto:rules-users at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org <mailto:rules-users at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org <mailto:rules-users at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org <mailto:rules-users at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-users
> <https://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/20071006/83340d02/attachment.html
More information about the rules-users
mailing list