| Cache not refreshing? [message #379590] |
Mon, 18 August 2008 08:14  |
Eclipse User |
|
|
|
Originally posted by: daniel.ortega.gmail.com
Hi everyone, I've just discovered a problem when updating one of my
entities; let's see if someone can help out:
I have a OneToMany relationship in a class named Issue:
@OneToMany(mappedBy="issue", cascade = CascadeType.ALL, fetch =
FetchType.LAZY)
@JoinTable(name="INCIDENCIA_ESTADO", joinColumns = @JoinColumn(name =
"ID_INCIDENCIA", referencedColumnName = "ID_INCIDENCIA"))
@OrderBy ("startDate")
private List<StateAssignment> states;
Issue objects can pass through many states on their life cycle and we
keep that information in the List name "states". The StateAssignment
entity has some properties: relevant for us now are just startDate and
endDate, both of them of type java.util.Date.
One issue can have only one state at a given time <=> only one of the
states of that list can have its endDate set to null.
I'll try to explain how the problem shows:
I made my tests having one Issue object with two StateAssignments (one
with endDate == null and the other not).
I add a new StatAssignment to my list (and put the last "active"
assignment's endDate to a "new Date()") and call the merge() method on
the EntityManager object.
That actually works fine, I can see how it updates the last
StateAssignment and sets its endDate, and also inserts a new row on the
table representing the new StateAssignment just added.
The problem comes when loading again that entity calling the find method
of the EntityManager. The Issue object comes without the new
StateAssignment (just the two original states on the list). Something
curious about it is that neither of those StateAssignment objects come
with their endDate set to null (remember one of them had it to null
before the update), so my Issue object represents just the half of the
update I just made.
It seems the StateAssignment objects are actually refreshing nice, but
the List that represent the relationship on the Issue class isn't, and
don't have any clue about it.
Maybe there's some way to force the EntityManager to load the Issue from
database skipping the cache (I don't want to deactivate it at all, just
force a fresh fetching for this case), or force the cache to be updated
just when the Issue object changes ... don't know.
I know I can use the refresh(Object) method of the EntityManager that
triggers a fresh read from DB but I don't know when this problem would
happen, so I would have to use the refresh() method ALWAYS when reading
from db and that would be the same as deactivating cache (I think).
Sorry for the length, but I though it was better to give you as many
information as possible.
Thanks in advance for your help
Daniel
|
|
|
|
| Re: Cache not refreshing? [message #379607 is a reply to message #379600] |
Tue, 19 August 2008 07:26  |
| Eclipse User |
|
|
|
Originally posted by: daniel.ortega.gmail.com
Pretty odd thing in fact, I changed the fetching of the relationship to
EAGER and that solved the problem .... I can't understand why; it might
be a bug or maybe I'm just doing something wrong.
That's not the best for us as we usually have lot's of states for one
Issue object and we (almost) always care just about the last one, but we
could live with that: we've been taken some measures and don't loose too
much performance.
By the way, what you mean with mantain the relationship correctly?
When adding a new StateAssignment I just create the objet, add it to the
list and merge the Issue object. The cascade on updating triggers the
insert of the new StateAssignment objet in the db.
At first I created the StateAssignment object, persisted it alone, then
I added to the list and merged the Issue object, but I found that was
redundant (I think).
On deleting I take the StateAssignment object off from the list, call
the remove method of EntityManager on that object and then merge the Issue.
That's been working correctly for me until now, is that the way this
kind of relationship is meant to be mantained?
Thanks.
|
|
|
|
Powered by
FUDForum. Page generated in 0.02889 seconds
] 
Search
Help
Register
Login
Home
