[EJB 3.0] - Very Weird, Triplicated childs at runtime, all ok in the DB
by raistlinmolina
Hello, I have (among other entities) one parent Entity called reportInstance and one child Entity Called reportParameterValue, the relation is OneToMany.
I have a strange problem that arised becauce I couldn't delete a parent object, when I tired to delete it's child I couldn't either.
Then I noticed that when I asked the parent for its childs I got them triplicated, all is ok in the database (childs not triplicated).
The child was a weak entity, having its PK formed by the PK of two tables, when I noticed this problem I tried:
*Adding an id filed as PK, now the child Entoty has it own pk (the former fileds forming the pk remain as Foreign Keys).
This didn't solve the problem, I couldn't delete anythimg and still got triplicated entries.
*Mapping the relationship in both sides, at first I had only mapped it at the Parent side as I didn't want to know a parent from the child.
This has solved the deletion problem but I still have triplicated childs!!!
I copy code snippets below:
The relation at ReportParameterValueEJB.java (the child)
@ManyToOne (targetEntity = ReportInstanceEJB.class, fetch = FetchType.EAGER)
| @JoinColumn (name = "idReportInstance", insertable=false, updatable=false)
| public ReportInstanceEJB getReportInstance(){
| return this.reportInstance;
| }
|
| public void setReportInstance(ReportInstanceEJB reportInstance){
| this.reportInstance = reportInstance;
| this.idReportInstance = reportInstance.getId();
| }
|
The relation at ReportInstanceEJB.java (the parent)
/**
| * Returns the value of the <code>reportParameterValue</code> relation property.
| *
| * @return the value of the <code>reportParameterValue</code> relation property.
| */
| @OneToMany(mappedBy="reportInstance", cascade= CascadeType.MERGE, fetch = FetchType.EAGER)
| public Collection <ReportParameterValueEJB> getReportParameterValues(){
| return parameterValues;
| }
|
| /**
| * Sets the value of the <code>reportParameterValue</code> relation property.
| *
| * @param parameters a value for <code>reportParameterValue</code>.
| */
| public void setReportParameterValues(Collection <ReportParameterValueEJB> parameters) {
| this.parameterValues = parameters;
| }
And now the traces I'm getting in the JBoss console:
10:36:57,612 INFO [STDOUT] Number of values:9
| 10:36:57,612 INFO [STDOUT] predelete: 10; 10; 2; 27
| 10:36:57,628 INFO [STDOUT] postdelete: 27
| 10:36:57,628 INFO [STDOUT] predelete: 10; 10; 2; 27
| 10:36:57,628 INFO [STDOUT] postdelete: 27
| 10:36:57,628 INFO [STDOUT] predelete: 10; 10; 2; 27
| 10:36:57,628 INFO [STDOUT] postdelete: 27
| 10:36:57,628 INFO [STDOUT] predelete: 12; 10; 2; 45
| 10:36:57,628 INFO [STDOUT] postdelete: 45
| 10:36:57,628 INFO [STDOUT] predelete: 12; 10; 2; 45
| 10:36:57,628 INFO [STDOUT] postdelete: 45
| 10:36:57,628 INFO [STDOUT] predelete: 12; 10; 2; 45
| 10:36:57,628 INFO [STDOUT] postdelete: 45
| 10:36:57,628 INFO [STDOUT] predelete: 13; 10; 2; 45
| 10:36:57,628 INFO [STDOUT] postdelete: 45
| 10:36:57,628 INFO [STDOUT] predelete: 13; 10; 2; 45
| 10:36:57,628 INFO [STDOUT] postdelete: 45
| 10:36:57,628 INFO [STDOUT] predelete: 13; 10; 2; 45
| 10:36:57,628 INFO [STDOUT] postdelete: 45
| ##########################################
| 10:42:59,471 INFO [STDOUT] Number of values:3
| 10:42:59,471 INFO [STDOUT] predelete: 16; 15; 2; 27
| 10:42:59,471 INFO [STDOUT] postdelete: 27
| 10:42:59,471 INFO [STDOUT] predelete: 16; 15; 2; 27
| 10:42:59,471 INFO [STDOUT] postdelete: 27
| 10:42:59,471 INFO [STDOUT] predelete: 16; 15; 2; 27
| 10:42:59,471 INFO [STDOUT] postdelete: 27
I explain the trace:
10:42:59,471 INFO [STDOUT] predelete: 16; 15; 2; 27
I call a println with: the childs id (PK) - 16, the childs FK to the report - 15 the childs id to another parent table - 2, and another field containing its value - 27
Then I call manager.remove(child);
and call an println with just its value just to make sure it was deleted without exceptiosn inside.
10:42:59,471 INFO [STDOUT] postdelete: 27
Here I deleted two different ReportInstances, id=10, and id=15 respectively.
Id=10 had 3 actual childs, and in the trace it says that it has nine
Id=15 had 1 actual child, and in the trace it says that it has three
The code at the agentBean that performs the ReportInstance deletion is:
public void deleteReportInstance(ReportInstanceEJB reportInstance) {
| Collection <ReportParameterValueEJB> values = reportInstance.getReportParameterValues();
| Iterator <ReportParameterValueEJB> valuesIt = values.iterator();
| System.out.println("Number of values:" + values.size());
| while (valuesIt.hasNext()){
| ReportParameterValueEJB value = valuesIt.next();
| System.out.println("predelete: " + value.getId()+"; "+ value.getIdReportInstance()+"; "+ value.getIdParameter()+"; "+value.getValue());
| manager.remove(value);
| System.out.println("postdelete: " + value.getValue());
| }
|
| manager.remove(reportInstance);
| }
I get one instance in the client, get a reference to the agentbean and ask it to delete the reportInstance as show above.
I have checked the database and I had only one child for reportInstance 10 and three for instance 15.
What's happening???
Thanks in advance
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973190#3973190
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973190
19 years, 7 months
[JBossCache] - Possible misunderstandig of the optimistic locking
by JL
Hallo,
after many trys to run the cluster under pessimistic locking, we want to change to optimistic locking.
Our cache has a lot of node like
/sentinel/[sessionId]
and /sentinel_Commands/[sessionId]
where [sessionId] is a unique identifier of an user. So the number of this
Fqn will scale with the number of logged in users.
All this nodes will be changed frequently. When I use the optimistic locking
I got the following exception during the commit phase and I'm mostly surprised about the line:
Caused by: org.jboss.cache.CacheException: DataNode [/] version Ver=74 is newer than workspace node Ver=73
Means this each change on a sub node will also increase the version of the root node and the commit phase will only work if there was no change in the complete treecache?
How it's possible that a commit works than if many cluster nodes will do changes on different (sub)nodes in the tree cache?
2006-09-21 09:52:23,321 [SentinelServerAgent_105] ERROR org.jboss.cache.transaction.DummyTransaction - beforeCompletion() failed for tx=org.jboss.cache.transaction.DummyTransaction@f91da9, handlers=[TxInterceptor.LocalSynchronizationHandler(gtx=GlobalTransaction:<192.168.4.174:7800>:78, tx=org.jboss.cache.transaction.DummyTransaction@f91da9)]
java.lang.RuntimeException:
at org.jboss.cache.interceptors.TxInterceptor$LocalSynchronizationHandler.beforeCompletion(TxInterceptor.java:1091)
at org.jboss.cache.interceptors.OrderedSynchronizationHandler.beforeCompletion(OrderedSynchronizationHandler.java:75)
at org.jboss.cache.transaction.DummyTransaction.notifyBeforeCompletion(DummyTransaction.java:247)
at org.jboss.cache.transaction.DummyTransaction.commit(DummyTransaction.java:54)
at org.jboss.cache.transaction.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:61)
at com.xtramind.common.distributed.DefaultDistributedResourceAgent.putData(DefaultDistributedResourceAgent.java:526)
at com.xtramind.common.distributed.DefaultDistributedResourceManager.putData(DefaultDistributedResourceManager.java:167)
at com.xtramind.common.sentinel.server.DefaultSentinelServerAgent.addCommand(DefaultSentinelServerAgent.java:805)
at com.xtramind.common.sentinel.server.DefaultSentinelServerAgent.answerToServerPing(DefaultSentinelServerAgent.java:255)
at com.xtramind.common.sentinel.server.DefaultSentinelServerAgent.run(DefaultSentinelServerAgent.java:320)
at java.lang.Thread.run(Thread.java:595)
Caused by: org.jboss.cache.CacheException: DataNode [/] version Ver=74 is newer than workspace node Ver=73
at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.simpleValidate(OptimisticValidatorInterceptor.java:127)
at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.validateNodes(OptimisticValidatorInterceptor.java:101)
at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.invoke(OptimisticValidatorInterceptor.java:66)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.OptimisticLockingInterceptor.invoke(OptimisticLockingInterceptor.java:95)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.OptimisticReplicationInterceptor.invoke(OptimisticReplicationInterceptor.java:74)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.TxInterceptor.runPreparePhase(TxInterceptor.java:804)
at org.jboss.cache.interceptors.TxInterceptor$LocalSynchronizationHandler.beforeCompletion(TxInterceptor.java:1069)
Thanks for help
JL
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973187#3973187
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973187
19 years, 7 months
[JBoss Seam] - Problems with the update method in Jboss Seam + Hibernate
by lara
I have an entity bean called Actor and a stateful session bean called ActorEditorBean. The database table for the entity bean contains many fields, one of them is "name" which should be unique. When I try to create an actor, I make sure first that there is no existing actor with that name since it should be unique. If it happens that the name is already used, I return an error message and the actor could not be created unless the name is changed. This works perfectly but the problem is that when I want to update an actor, the same process should be done. I tried to follow the code step by step but I am not able to know when exactly the update is done. It seems that even without calling the update method explicitly, it is being called implicitly or maybe because of the entity manager. I would be very thankful if anyone can help!
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973182#3973182
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973182
19 years, 7 months