[JBoss Seam] - Problem synchronizing managed-persistence-context
by cpopetz
I'm experiencing the following problem with seam 2.0.0CR3, hibernate 3.2.5ga, hibernate EM 3.3.1 GA. I'm running with the embedded jboss EJB3 container that's packaged with seam, so I'm not sure of its version number, but I don't think this behavior is specific to the embedded container.
I have a managed-persistence-context and a factory to inject its session delegate, almost straight out of the manual:
<persistence:managed-persistence-context name="discussionEM"
auto-create="true"
persistence-unit-jndi-name="<the path to my factory>"/>
<factory name="discussionSession" auto-create="true" value="#{discussionEM.delegate}"/>
Here's the use-case. A non-transactional method calls a method on a SFSB bean that has the discussionSession injected with @In. When that happens, the container sets up a transaction, and when discussionEM is @Unwrapped it calls joinTransaction, the entity manager joins the transaction, and everything is cool. That method returns, and the transaction is committed and removed. Now my non-transactional caller calls _another_ method on the same SFSB. This time, the container sets up a transaction, but @Unwrap is never called on discussionEM, because the discussionSession is found in the event context, and here is no component named "discussionSession" (since it's a factory), so no unwrap method is called, so no synchronization happens.
So is there something I'm doing wrong? My feeling is that if ManagedPersistenceContext is going to do important things in @Unwrap, then @Unwrap needs to be called on every injection, which it's not (at least in this case.)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101409#4101409
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101409
18 years, 5 months
[JBossCache] - Re: Initial State Transfer Failure
by bstansberry＠jboss.com
I think your problem is in PING:
initial_hosts="192.168.181.191[48866]
If you are going to use this, the port associated with the peer is not the UDP.mcast_port (48866), it is the UDP.bind_port, which you would need to specify in UDP. If you specify PING.initial_hosts, PING sends UDP unicast messages to each listed member; it does not send a multicast. For the unicast message it needs to know the UDP.bind_port. If you don't specify bind_port, UDP picks an ephemeral port, which obviously you can't list in initial_hosts.
With your config, what happens is the initial group discovery fails and each node forms a group by itself. No initial state transfer when you are in a group by yourself. Then MERGE2 kicks in and the groups merge into a single cluster. But a merge does not trigger an initial state transfer.
Why are you specifying initial_hosts? Don't if you don't really need to; it's not the usual way to use PING.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101400#4101400
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101400
18 years, 5 months