Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EclipseLink » Changing lazy attributes when shared cache disabled
Changing lazy attributes when shared cache disabled [message #1252185] Fri, 21 February 2014 01:38 Go to next message
Peter Nehrer is currently offline Peter NehrerFriend
Messages: 241
Registered: July 2009
Senior Member
Hi,

I observe the following behavior when I disable shared cache via <property name="eclipselink.cache.shared.default" value="false"/>:

1. start transaction
2. fetch existing object
3. change eager property
4. change lazy (lob) property
5. change another eager property
6. commit and close

The change in #3 gets lost -- the field doesn't even show up in the UPDATE statement.

With shared cache enabled, that is not the case.

Is this expected or a bug? Refreshing the object or locking it beforehand doesn't seem to help. Am I expected to ensure all lazy attributes that I intend to modify are loaded up-front? I can do that; it just seems odd.

Thanks in advance for any insight.
Re: Changing lazy attributes when shared cache disabled [message #1256850 is a reply to message #1252185] Tue, 25 February 2014 21:45 Go to previous message
Chris Delahunt is currently offline Chris DelahuntFriend
Messages: 1389
Registered: July 2009
Senior Member
If this is all happening in the same EntityManager context, on the same managed entity, it is unexpected and seems like fetching the lazy attribute might be forcing a refresh to occur. Check the state of the property changed in step 2 within the entity before and after step 3 to see if it is changed by trenching the lazy attribute or if something else might be happening.
Previous Topic:Reload Persistence Unit at Runtime
Next Topic:JPQL count query slow
Goto Forum:
  


Current Time: Thu Apr 25 12:57:41 GMT 2024

Powered by FUDForum. Page generated in 0.03100 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top