| Adding/removing relations [message #1089953] |
Mon, 19 August 2013 09:51  |
Eclipse User |
|
|
|
Eclipselink 2.5, Glassfish 3.1.2.2, container managed context and in this case extended persistence context (but same happens also without the extended context).
I have a few @ManyToMany relations and something has me stumped.
When user starts editing an objects, the @Stateful EJB bean fetches the object editingObj and stores it.
editingObj = em.find(Obj.class, objId);
Now when user wants to add a related object a function fetches the related object relatedObj by id and checks if it is already present in the relation.
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
function a() {
// fetch
relatedObj = em.find(Obj.class, relObjId);
// check
if (relatedObj.getObjects().contains(editingObj) || editingObj.getObjects().contains(relatedObj))
throw new EJBException("cannot add existing relatedobject");
Problem is object references from relation are not the same as object reference I get from em.find(). So the list of objects (relation) never contains the target object. I guess I am expecting too much and must check objectID field for identity...
Is there another way of finding out identity? How could I maintain a relation that won't get duplicated? I have a separate PK column in the intersecting table so relation can get inserted (unless I'd have set unique indices but I'd rather not have SQL exceptions in this case since it would show only after saving).
I know I can always check object's id's, but is there another nicer way of doing this in Eclipselink (jpa)?
|
|
|
|
|
| Re: Adding/removing relations [message #1090639 is a reply to message #1090044] |
Tue, 20 August 2013 08:37  |
| Eclipse User |
|
|
|
Yea I remember reading about this a while ago but then I just discarded it since it was not important then... it definitely is now. Thanks!
The thing is I like how extended persistence context works in my case: I want to stack changes from several methods and apply them when user clicks save. There is a slight problem of multiple users editing the same object and locks don't seem to solve it at all, so I will probably just implement locking at the application level (maybe some idea why locking em.lock() doesn't work? I've tried all possible lock types and it will still allow another user to lock the same object again... I guess it could be another EM instance problem as it is here).
Problem with transactions here is that my methods don't support transactions. From what I've read of EJB transactions other method can merge existing transaction (that is what you were talking about), but can I make this work in my case? Maybe NOT_SUPPORTED is unnecessary? I still want all the user's changes to be applied only when I call em.flush() and not before. I am a bit far into this though, so I guess fetching a few objects won't hurt right now... but I don't have the luxury of time to learn and experiment anymore.
Oh and regarding caching entities in session beans, I am only holding onto two objects: the item user is editing and user object itself since I have to link them too. Problem is objects are quite deeply linked in the schema and there are a ton of relations. This shouldn't be too much or is it? The other way of doing things was to merge a detached object from jsf session when editing is complete, but I had huge problems with relations propagating weirdly and even bigger problems when checking for existing relations. At least all that is solvable now as it is I think. I am quite sure concurrent editing will be very rare.
Thanks again though, I will post more if I manage to find out something new regarding this.
|
|
|
Powered by
FUDForum. Page generated in 0.06041 seconds
Home