[jboss-user] [EJB 3.0] - Re: problems with optimistic locking/persistence data in EJB

wiggy do-not-reply at jboss.com
Thu Jan 24 06:15:31 EST 2008


Wayne, 

thanks for the comment - been off line getting an arthroscopy so just picked up your reply .

I  think I still have a copy of problems here that i cant make sense of.

I can see that the client has serialised the uNode/Znode and passed this to the server which has run the NodeEAO.Remove method - and therefore whilst the local references held at the server are updated - there is no return and therefore the client still references a local proxy thats now out of step with the server.

however what i then do is try to resynchronise my local copy uNode against the database.  I do this on the client side - just cos its easier to work with the debugger and watch it.


  | client side ...
  | 
  |                                                 //call server side delete action in EJB 
  |                                                 // this successfuly deletes the link in the DB
  |                                                 // but doesnt update the local uNode 
  | 			if (nodeEAO.removeLink(uNode, zNode))
  | 			{
  | 
  | 				System.out.println ("deleted link  : \n");
  | 			}
  | 
  |                                                 //try a local resynch to get in step
  | 			yNode = resynch (uNode);
  |  


This has behaves as follows.  The now stale uNode is passed into this routine.  I create a local Entity Manager (dont go to the server this time) and try and merge the uNode to a persistence context.

The merge action queues an update to the database as the stale uNode has two link references (whereas the database now has one because of the previous remove action).

I then call the em.refresh action - hoping to resync the uNode with the DB - however the previous queued updated kicks in first and it the DB is left with new links added (i have transitive persist/merge set on the uNode.myLinks collection)

what i expected to have happen was that the instance would be overwritten by the refresh - but the queued merge kicks in first.


  | 
  | 	public static Node resynch (Node fromNode)
  | 	{
  | 		EntityManager em;
  | 		EntityManagerFactory emf ;
  | 		List<Link> res;
  | 		boolean result = false;
  | 
  | 		emf = Persistence.createEntityManagerFactory("embedDS");
  | 
  | 		em = emf.createEntityManager();
  | 
  | 		try
  | 		{
  | 		EntityTransaction t = em.getTransaction(); 
  | 
  | 		t.begin();
  |                                 //queues an update from stale uNode
  | 		Node mergedNode = em.merge(fromNode);
  | 
  |                                 //refresh reads back queued model
  | 		em.refresh(mergedNode);
  | 
  | 		t.commit();
  | 		return mergedNode;
  | 		} 
  | 		finally 
  | 		{
  | 			em.close();
  | 			emf.close();
  | 		}
  | 
  | 	}
  | 
  | 
  | 

This code actually puts the link back in the DB that i'd just deleteted on the server.

so i dont understand how refresh is supposed to work - I thought it was supposed to update the instance you merge with the current DB state - (effectively an undo action).  In reality my stale data gets recommitted and I cant refresh the node as expected.

How am I supposed to resync a current client copy after the call on the server.  Do i have to just just a em.find /query to get latest.

I dont understand what the books tell me vs what I see when i watch the code go through in the debugger and watch the db 



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122979#4122979

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122979



More information about the jboss-user mailing list