[jpa-spec users] [jsr338-experts] Re: lazy associations [was Re: Re: Re: changes for 7.6.2 Container-managed Transaction-scoped

From: Gordon Yorke <>
Date: Mon, 05 Dec 2011 17:19:54 -0400

Hello All,
    "fetch groups" or "operation groups" do have their usefulness for pre-serialization processing and merging. Whatever structures are created it would be valuable to define them a generic way allowing them to be applied to other operations other than just attribute loading.


On 12/5/2011 5:32 AM, Rainer Kwesi Schweigkoffer wrote:
> Hi Linda, all,
> me, I think we should have a look into the fetch groups/profile
> stuff. From my point of view it's awfully needed to establish a
> contract on what has been loaded.
> Best regards
> Rainer
> Am 2 Dec 2011 um 13:33 hat Linda DeMichiel geschrieben:
>> Thanks, Scott.
>> Changing the subject and snipping out the previous discussion here so that the
>> Scott's suggestion doesn't get buried in the thread....
>> On 12/1/2011 8:37 PM, Scott Marlow wrote:
>>> I was thinking more about the lazy associations problem. Is there room in the JPA 2.1 specification, to make an
>>> enhancement that improves what applications experience when the entity manager is invoked outside the scope of a
>>> transaction? I'm thinking that the container could have a way to give a hint to the persistence provider, that lazy
>>> fetching should not be used for the entity manager invocation. The advantage of this enhancement, is that applications
>>> will successfully be able to access the loaded entity(s) that currently fail (due to lazy fetching being used). I think
>>> that the application can also make changes to work around this (e.g. use FetchType.EAGER) but I would like the same
>>> (FetchType.LAZY) entity/association to work with both container/app managed entity managers (that don't run in a JTA
>>> transaction).
>>> Perhaps this could be a (new) standard property that the container could pass to
>>> EntityManagerFactory.createEntityManager(Map) that suggests that lazy fetching should be disabled. Or something more
>>> generic that covers other possible problems. e.g. some hint like "" that lets the provider
>>> know that loaded entities will be detached (so the provider can avoid using lazy fetching).
>> Folks, I'd like to get more opinions on this. Should we pursue this direction?
>> Should we try to address this issue via fetch groups/profiles? Other?
>> thanks,
>> Linda
> ---
> Rainer Schweigkoffer SAP AG Walldorf
> Business Solution& Technology TD Core JI
> Technology Development Dietmar-Hopp-Allee 16
> Java Server Core D-69190 Walldorf
> JEE Implementation Group phone: +49 6227 7 45305
> Building 3, I.3.14 fax: +49 6227 7 821177
> Sitz der Gesellschaft/Registered Office: Walldorf, Germany
> Vorstand/SAP Executive Board: Werner Brandt, Bill McDermott (Co-CEO),
> Gerhard Oswald, Vishal Sikka, Jim Hagemann Snabe (Co-CEO)
> Vorsitzender des Aufsichtsrats/Chairperson of the SAP Supervisory
> Board: Hasso Plattner
> Registergericht/Commercial Register Mannheim No HRB 350269
> Diese E-Mail kann Betriebs- oder Geschaeftsgeheimnisse oder sonstige
> vertrauliche Informationen enthalten. Sollten Sie diese E-Mail
> irrtuemlich erhalten haben, ist Ihnen eine Verwertung des Inhalts,
> eine Vervielfaeltigung oder Weitergabe der E-Mail ausdruecklich
> untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die
> empfangene E-Mail. Vielen Dank.
> This e-mail may contain trade secrets or privileged, undisclosed, or
> otherwise confidential information. If you have received this e-mail
> in
> error, you are hereby notified that any review, copying, or
> distribution
> of it is strictly prohibited. Please inform us immediately and
> destroy the
> original transmittal. Thank you for your cooperation.