[JBossCache] - Duplicate notifications to separate PojoCacheListener instan
by mc.coder
I'm having an issue which I think is not supposed to be happening.
I read the javadoc for PojoCacheImpl.addListener and it says "A given listener instance can only be added once, whether or not there is a pattern. To have a duplicate listener simply create a new instance."
I am experiencing the following behavior. When I add 1 listener to a cache I get one notification event per change to the cached object. When I add 2 listeners (different instances, or even two instances of listeners of different object types) I get 4 notifications for every change to a cached object. Adding the second listener behaves as though it were creating a second instance of the CacheListenerAdapter in the PojoCacheImpl adding both listeners seem to be added to both adapters (creating a cross product of 4). I say this because when I print out the context from the events (e.getContext()) I can see that the 2 duplicate event notifications are coming from two distinct CacheListenerAdapter instances.
Is anyone else experiencing this or am I doing something very wrong? This doesn't seem to me to be correct behavior.
Output from run with 1 listener instance:
Node attached: org.jboss.cache.pojo.notification.event.AttachedEvent[source=1: integer]
| Event.getContext(): org.jboss.cache.pojo.impl.CacheListenerAdaptor$1@6214f5
Output from run with 2 different instances:
Node attached: org.jboss.cache.pojo.notification.event.AttachedEvent[source=1: integer]
| Event.getContext(): org.jboss.cache.pojo.impl.CacheListenerAdaptor$1@4d76b4
| Node attached: org.jboss.cache.pojo.notification.event.AttachedEvent[source=1: integer]
| Event.getContext(): org.jboss.cache.pojo.impl.CacheListenerAdaptor$1@4d76b4
| Node attached: org.jboss.cache.pojo.notification.event.AttachedEvent[source=1: integer]
| Event.getContext(): org.jboss.cache.pojo.impl.CacheListenerAdaptor$1@19b46dc
| Node attached: org.jboss.cache.pojo.notification.event.AttachedEvent[source=1: integer]
| Event.getContext(): org.jboss.cache.pojo.impl.CacheListenerAdaptor$1@19b46dc
As always, many thanks..
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4112764#4112764
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4112764
18 years, 4 months
[JBoss Seam] - Re: how to dis-manage entities?
by gsegura
perhaps the topic name was not the best, but I think its a fair question.
So far, only strategy to avoid the entity which holds the collection to get updated is to resort to deal with id alone, a not very object-oriented way to go, so instead of retrieving the ticket.course object fetch just the id:
Integer idCourse = (Integer)entityManager
| .createQuery("select t.course.id from Ticket t where t.code=#{register.code}")
| .getSingleResult();
But I don't know if dealing with IDs is the proper way to go with respect to ORM techniques.
At the same time this makes think of another issue: the implementation of master-detail editions, which at first, for the neophyte like me, feels natural to handle using nested conversations and sharing full objects but the preferred way to go is using entityhome and its passing-just-the-id technique, again a not very OO-ish way IMHO.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4112762#4112762
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4112762
18 years, 4 months