Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-users] Serious bug in EclipseLink sequencepre-allocation


Thanks for your helpful response.

I made a testcase which did not reproduce my initial observation so
there is no issue fortunately. I guess I used getReference() at the
time which confused me.

EclipseLink is "reconnecting to external connection pool" to get
lazily fetched entities after the persistence context is closed. I
first thought that I could not take such functionality for granted.

Bug 237358 is not clear enough to me. It would be nice to have a

Best regards,


On Thu, 18 Mar 2010 08:29:04 -0400, you wrote:

>Hello Bernard,
>Can you please give an example or details of the feature you are saying 
>worked in TLE and isn't working in EclipseLink - for example a 
>particular mapping, how you are obtaining the entity etc?  I cannot tell 
>if this is related to the getReference bug you filed or if it is a 
>different issue.   Did you get a chance to look at bug 237358 and see if 
>it is related? 
>As mentioned, lazy relationships are still fetchable once the context is 
>closed, the same as it was in TLE.  If attributes (such as basics) are 
>marked lazy and not fetchable once the context is closed in EclipseLink 
>- EclipseLink added support for fetch groups that TLE never had, and 
>there maybe issues with accessing these when the context is closed (as 
>in bug 237358).  If that is the case, not marking your basic mappings as 
>lazy and using find instead of getReference will give you the same 
>behavior you had in TLE. 
>bht@xxxxxxxxxxxxx wrote:
>> Hi Chris,
>> The details are that the context is per definition no longer available
>> afaik. What astonishes me is that TopLink Essentials still provides
>> some kind of extended context unexpectedly, so, may be, one could say,
>> TLE has the context while EclipseLink doesn't. I enjoyed that feature
>> and utilised it in the web tier.
>> I have a plain vanilla transaction scoped Entitymanager in a stateless
>> session bean. The web tier calls a session bean method and works with
>> the entity returned by the session bean.
>> The feature broke when I switched to EclipseLink. I was not surprised
>> as I had I annotated my code with warnings.
>> My question is whether this behavior which is probably a TopLink
>> Essentials feature that does not conform with the specification, is
>> something that can be had by other means or whether I should just
>> forget about it, or whether I should file a bug against TLE?
>> Many thanks again,
>> Bernard
>> On Wed, 17 Mar 2010 09:32:43 -0400, you wrote:
>>> Hello Bernard,
>>> EclipseLink still allows access to lazy relationships if the context is 
>>> still available., the same as in TLE. 
>>> Can you give more details on what you are referring to and if 
>>> serialization is involved? Could this be related to bug 237358?
>>> If it is the issue in 237358 note that TLE would eagerly fetch all 
>>> non-relationships; the solution is to make them eager to get the TLE 
>>> behavior until EclpseLink
>>> can allow initializing lazy attributes outside the context like it does 
>>> relationships. 
>>> Regards,
>>> Chris
>>> bht@xxxxxxxxxxxxx wrote:
>>>> Hi,
>>>> I noticed a difference between TopLink Essentials and EclipseLink. 
>>>> Outside a session bean method of a transaction scoped Entitymanager,
>>>> TopLink Essentials would retrieve lazily fetched properties, leading
>>>> to traceable database calls. That does not work in EclipseLink.
>>>> Can I just forget about this "feature" or is there a supported method
>>>> of fetching this way (read only of course). I understand this sounds a
>>>> bit messy, because it may cause resource leak issues, but I am asking
>>>> because it DID work.
>>>> Many thanks,
>>>> Bernard
>>>> _______________________________________________
>>>> eclipselink-users mailing list
>>>> eclipselink-users@xxxxxxxxxxx
>>> _______________________________________________
>>> eclipselink-users mailing list
>>> eclipselink-users@xxxxxxxxxxx
>> _______________________________________________
>> eclipselink-users mailing list
>> eclipselink-users@xxxxxxxxxxx
>eclipselink-users mailing list

Back to the top