2:48 p.m.
I know the threading topic has been discussed quite extensively, but I still
need some guidance in the following case:
My application has a RuleManager object that maintains references to many
RuleBase objects in a HashMap. I'm using Spring Framework to wire the bean
relationships together.
The RulesManager is typically busy servicing client requests for instances
of WorkingMemory objects which it fetches from the individual RuleBase
objects it maintains in its Hash (wm.newWorkingMemory() ).
From time to time, I'll need RulesManager to reaload the rules
that are
associated with the individual RuleBase object - for that, I'm going
to
create a new instance of the RuleBase object and then I need an efficient
and safe way to 'swap' this new RuleBase object for the old object reference
in the RulesManager's map.
My question is: should I synchronize the getWorkingMemory(..) method inside
my RulesManager object that uses the hashmap, AND also synchronize the code
that does the object swap - would that be sufficient?! How would I do it
using Collections.synchronizedMap() - remember that I don't have that much
control over the creation of the Map since Spring controls that part of
populating hashmap at startup.
The critical factors for me are speed and efficiency in servicing regular
client requests for WorkingMemory - ideally, I'd synchronize only the method
that does the object swap, but I'm sure that may have some bad
consequences... though as long as I can avoid the race condition I could
probably live with it.
Thanks in advance for ideas -
--
View this message in context:
http://www.nabble.com/Question-on-data-safety-and-threading...-tf3396050....
Sent from the drools - user mailing list archive at Nabble.com.
12:32 a.m.
in your case - as you are swapping out the RuleBase - I woudl suggest
locking or syncing things when swapping - not sure how to do that given that
spring is in control.
Also, i would suggest you use RuleBase#newWorkingMemory(false) so that it
doesn't keep a weakhashmap around pointint back to the working memories, as
you don't need it (it will mean less big GC pauses under heavy load in your
case).
Michael.
On 3/13/07, jdepaul <jjdepaul(a)us.ibm.com> wrote:
I know the threading topic has been discussed quite extensively, but I
still
need some guidance in the following case:
My application has a RuleManager object that maintains references to many
RuleBase objects in a HashMap. I'm using Spring Framework to wire the bean
relationships together.
The RulesManager is typically busy servicing client requests for instances
of WorkingMemory objects which it fetches from the individual RuleBase
objects it maintains in its Hash (wm.newWorkingMemory() ).
>From time to time, I'll need RulesManager to reaload the rules that are
associated with the individual RuleBase object - for that, I'm going to
create a new instance of the RuleBase object and then I need an efficient
and safe way to 'swap' this new RuleBase object for the old object
reference
in the RulesManager's map.
My question is: should I synchronize the getWorkingMemory(..) method
inside
my RulesManager object that uses the hashmap, AND also synchronize the
code
that does the object swap - would that be sufficient?! How would I do it
using Collections.synchronizedMap() - remember that I don't have that much
control over the creation of the Map since Spring controls that part of
populating hashmap at startup.
The critical factors for me are speed and efficiency in servicing regular
client requests for WorkingMemory - ideally, I'd synchronize only the
method
that does the object swap, but I'm sure that may have some bad
consequences... though as long as I can avoid the race condition I could
probably live with it.
Thanks in advance for ideas -
--
View this message in context:
http://www.nabble.com/Question-on-data-safety-and-threading...-tf3396050....
Sent from the drools - user mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
9:24 p.m.
jdepaul,
We are implementing a diferent solution for that. We are using a
Topic JMS using spring, so we have build diferent RuleBases and
publish them
in this topicJMS as a post, then a WorkingMemoryFactory has a
listener for changes on the topics, and when that happens the factory
refresh the
singleton reference to the RuleBase (sincronyzed) and provides a
newWorkingMemory... no maps, one factory for each rulebase (we have
them identified)
and the diferent ruleBases are managed by diferent topic-beans-names
in the spring configuration. I guess it can be managed by maps too.
We will send the code in 3 weeks when we have it tested and operative.
Good luck!.
On 13-03-2007, at 19:32, Michael Neale wrote:
in your case - as you are swapping out the RuleBase - I woudl
suggest locking or syncing things when swapping - not sure how to
do that given that spring is in control.
Also, i would suggest you use RuleBase#newWorkingMemory(false) so
that it doesn't keep a weakhashmap around pointint back to the
working memories, as you don't need it (it will mean less big GC
pauses under heavy load in your case).
Michael.
On 3/13/07, jdepaul <jjdepaul(a)us.ibm.com> wrote:
I know the threading topic has been discussed quite extensively,
but I still
need some guidance in the following case:
My application has a RuleManager object that maintains references
to many
RuleBase objects in a HashMap. I'm using Spring Framework to wire
the bean
relationships together.
The RulesManager is typically busy servicing client requests for
instances
of WorkingMemory objects which it fetches from the individual RuleBase
objects it maintains in its Hash ( wm.newWorkingMemory() ).
>From time to time, I'll need RulesManager to reaload the rules
that are
associated with the individual RuleBase object - for that, I'm
going to
create a new instance of the RuleBase object and then I need an
efficient
and safe way to 'swap' this new RuleBase object for the old object
reference
in the RulesManager's map.
My question is: should I synchronize the getWorkingMemory(..)
method inside
my RulesManager object that uses the hashmap, AND also synchronize
the code
that does the object swap - would that be sufficient?! How would I
do it
using Collections.synchronizedMap() - remember that I don't have
that much
control over the creation of the Map since Spring controls that
part of
populating hashmap at startup.
The critical factors for me are speed and efficiency in servicing
regular
client requests for WorkingMemory - ideally, I'd synchronize only
the method
that does the object swap, but I'm sure that may have some bad
consequences... though as long as I can avoid the race condition I
could
probably live with it.
Thanks in advance for ideas -
--
View this message in context: http://www.nabble.com/Question-on-
data-safety-and-threading...-tf3396050.html#a9454823
Sent from the drools - user mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://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
Felipe Piccolini M.
felipe.piccolini(a)bluesoft.cl
6254
days inactive
6262
days old
2 comments
3 participants
participants (3)
-
Felipe Piccolini -
jdepaul -
Michael Neale