[EJB 3.0] - Foreign Key fields not set for child entity
by lafr
My parent Entity looks like this:
public class MbiMsghd implements java.io.Serializable
| {
| /** Field msghdSerial. */
| @Id
| @GeneratedValue(strategy=GenerationType.IDENTITY)
| @Column(name="msghd_serial")
| private java.lang.Integer msghdSerial;
| /** Relation with MbiMsgpa. */
| @OneToMany(cascade=CascadeType.ALL,fetch=FetchType.LAZY,mappedBy="msghdSerial")
| @OrderBy("msghdSerial,partNo")
| private java.util.Collection<MbiMsgpa> mbiMsgpa = new java.util.ArrayList<MbiMsgpa>();
|
My child entity like this:
@Entity
| @IdClass(value=MbiMsgpa.PK.class)
| @Table(name="mbi_msgpa")
| public class MbiMsgpa implements java.io.Serializable
| {
| /** Field msghdSerial. */
| @Id
| @ManyToOne
| @Column(name="msghd_serial")
| private java.lang.Integer msghdSerial;
|
| /** Field partNo. */
| @Id
| @Column(name="part_no")
| private java.lang.Integer partNo;
|
So the child has a composite primary key and one part of this PK is a FK to the parent.
In my session bean I can create the parent successfully, but the created and added child did not get set the PK/FK fields.
MbiMsgpa mbiMsgpa = new MbiMsgpa();
| mbiMsghd.getMbiMsgpa().add( mbiMsgpa );
| // set all attributes of child entity
| this.entityManager.persist( mbiMsgpa );
|
The key values of the child entity are null when they are inserted into the database.
>From all examples I saw in my book and on the Web I expected the EJB3 container to set the key fields of the child entity.
It does not make any difference if I set up the OneToMany relation uni- or bidirectional.
Did anyone of you get something like this running on JBoss 4.2.2.GA?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4083668#4083668
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4083668
18 years, 8 months
[JBossCache] - FetchInMemoryState + jgroups config
by nnnnn
I'm having trouble getting things configured properly to get the state transferred to a new server joining a cluster (jbosscache 2.0.0GA). Relevant config:
| <attribute name="ClusterConfig">
| <config>
| <UDP mcast_addr="228.1.2.3" mcast_port="48866"
| ip_ttl="64" ip_mcast="true"
| mcast_send_buf_size="150000" mcast_recv_buf_size="80000"
| ucast_send_buf_size="150000" ucast_recv_buf_size="80000"
| loopback="false"/>
| <PING timeout="10000" num_initial_members="3"/>
| <MERGE2 min_interval="1000" max_interval="2000"/>
| <FD shun="true"/>
| <FD_SOCK/>
| <VERIFY_SUSPECT timeout="1500"
| up_thread="false" down_thread="false"/>
| <pbcast.NAKACK gc_lag="50" retransmit_timeout="600,1200,2400,4800"
| max_xmit_size="8192"/>
| <UNICAST timeout="600,1200,2400"/>
| <pbcast.STABLE desired_avg_gossip="400000"/>
| <pbcast.GMS join_timeout="5000" join_retry_timeout="20000"
| shun="true" print_local_addr="true" leave_timeout="3000"/>
| <FC max_credits="2000000"
| min_threshold="0.20"/>
| <FRAG2 frag_size="8192"/>
| <pbcast.STREAMING_STATE_TRANSFER/>
| </config>
| </attribute>
| <attribute name="FetchInMemoryState">true</attribute>
| <attribute name="StateRetrievalTimeout">60000</attribute>
|
What I get in the log indicates that JGroups is timing out before it can join the group (related log messages shown. IP of machine joining is 1.1.1.1. IP of machine already up is 9.9.9.9):
| 2007-09-12 14:26:51,443 DEBUG [org.jboss.cache.CacheImpl.MyCluster] (main) cache mode is REPL_ASYNC
| 2007-09-12 14:26:51,453 INFO [org.jgroups.JChannel] (main) JGroups version: 2.5.0
| 2007-09-12 14:27:01,691 INFO [org.jboss.cache.CacheImpl.MyCluster] (main) viewAccepted(): [1.1.1.1:32774|0] [1.1.1.1:32774]
| 2007-09-12 14:27:01,709 INFO [org.jboss.cache.CacheImpl.MyCluster] (main) CacheImpl local address is 1.1.1.1:32774
| 2007-09-12 14:27:01,709 DEBUG [org.jboss.cache.CacheImpl.MyCluster] (main) State could not be retrieved (we are the first member in group)
| 2007-09-12 14:27:01,710 INFO [org.jboss.cache.CacheImpl.MyCluster] (main) JBoss Cache version: JBossCache 'Habanero' 2.0.0.GA[ $Id: Version.java,v 1.35 2007/08/01 16:52:13 msurtani Exp $]
| 2007-09-12 14:27:03,046 INFO [org.jboss.cache.CacheImpl.MyCluster] (Incoming Thread,MyCluster,1.1.1.1:32774) viewAccepted(): MergeView::[9.9.9.9:32781|19] [9.9.9.9:32781, 1.1.1.1:32774], subgroups=[[9.9.9.9:32781|18] [9.9.9.9:32781], [1.1.1.1:32774|0] [1.1.1.1:32774]]
|
So I should increease the ping timeout, right? Probably only need a few seconds, since the other server's group was merged with this one only 2 seconds after this JGroups declared that it couldn't find the other one.
So I changed the timeout for PING to 200000 (200 seconds, much longer). However, this is the result:
| 2007-09-12 14:18:41,098 DEBUG [org.jboss.cache.CacheImpl.MyCluster] (main) cache mode is REPL_ASYNC
| 2007-09-12 14:18:41,108 INFO [org.jgroups.JChannel] (main) JGroups version: 2.5.0
| 2007-09-12 14:22:01,344 INFO [org.jboss.cache.CacheImpl.MyCluster] (main) viewAccepted(): [1.1.1.1:32773|0] [1.1.1.1:32773]
| 2007-09-12 14:22:01,362 INFO [org.jboss.cache.CacheImpl.MyCluster] (main) CacheImpl local address is 1.1.1.1:32773
| 2007-09-12 14:22:01,362 DEBUG [org.jboss.cache.CacheImpl.MyCluster] (main) State could not be retrieved (we are the first member in group)
| 2007-09-12 14:22:01,363 INFO [org.jboss.cache.CacheImpl.MyCluster] (main) JBoss Cache version: JBossCache 'Habanero' 2.0.0.GA[ $Id: Version.java,v 1.35 2007/08/01 16:52:13 msurtani Exp $]
| 2007-09-12 14:22:04,245 WARN [org.jgroups.protocols.pbcast.NAKACK] (Incoming Thread,MyCluster,1.1.1.1:32773) 1.1.1.1:32773] discarded message from non-member 9.9.9.9:32781, my view is [10.195.70.107:32773|0] [1.1.1.1:32773]
| 2007-09-12 14:22:04,246 WARN [org.jgroups.protocols.pbcast.NAKACK] (Incoming Thread,MyCluster,10.195.70.107:32773) 1.1.1.1:32773] discarded message from non-member 9.9.9.9:32781, my view is [1.1.1.1:32773|0] [1.1.1.1:32773]
| 2007-09-12 14:22:04,248 INFO [org.jboss.cache.CacheImpl.MyCluster] (Incoming Thread,MyCluster,1.1.1.1:32773) viewAccepted(): MergeView::[9.9.9.9:32781|17] [9.9.9.9:32781, 1.1.1.1:32773], subgroups=[[9.9.9.9:32781|16] [9.9.9.9:32781], [1.1.1.1:32773|0] [1.1.1.1:32773]]
|
|
What happens is that after the 200 seconds expire, JGroups decides that it's alone, no state transfer happens, and then 4 seconds later, JGroups decides that the other server exists. Too late for state transfer.
Am I misconfiguring something? Misunderstanding something?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4083665#4083665
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4083665
18 years, 8 months
[Clustering/JBoss] - Re: HA-JMS
by bstansberry＠jboss.com
Basically, it's the JGroups coordinator for the jboss:service=DefaultPartition channel, i.e. the first member shown in the "CurrentView" attribute for that mbean [1].
99% case: JGroups coordinator is the node that's been a member of the cluster the longest. The view is ordered by when nodes joined.
1% case: there was some network disruption and the cluster fell apart into more than one subgroup. Then the disruption ended and the subgroups merged. In that case the view will be ordered based on the IP address / port of the members, so the coordinator will be the one that sorts first.
[1] Odd case: you're not using deploy-hasingleton on all nodes in the cluster. In that case, the master will be the first node in the view where deploy-hasingleton is used. Rules for ordering the view are as described above.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4083664#4083664
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4083664
18 years, 8 months
[JBoss jBPM] - Re: bpws.getVariableData as predicate is not supported?
by alex.guizar＠jboss.com
In case you are interested: AssignReader captures the namespace declarations in scope when parsing the query. When the evaluator is constructed, a SetNamespaceContext is initialized with the namespace declaration and set as the evaluator's namespaceContext property.
The function library is an attribute of the XPathQueryEvaluator class and is best set in QueryEvaluator instances by overriding the createFunctionContext method:
protected FunctionContext createFunctionContext() {
| return functionLibrary;
| }
The VariableContext depends on the token argument. Because multiple tokens could evaluate the same query simultaneously, it is not advisable to set it as the evaluator's variableContext property. Try the following:
public Object evaluate(Node contextNode, Token contextToken) {
| Context context = createContext(contextNode, contextToken);
| try {
| List nodeSet = selectNodes(context);
| return narrowToSingleNode(nodeSet);
| }
| catch (JaxenException e) {
| log.error("query evaluation failed", e);
| throw new BpelFaultException(BpelConstants.FAULT_SUB_LANGUAGE_EXECUTION);
| }
| }
|
| private Context createContext(Node contextNode, Token contextToken) {
| ContextSupport support = new ContextSupport(getNamespaceContext(), getFunctionContext(),
| new TokenVariableContext(contextToken), getNavigator());
|
| Context context = new Context(support);
| context.setNodeSet(Collections.singletonList(contextNode));
| return context;
| }
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4083660#4083660
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4083660
18 years, 8 months