Agreed. Using the scope of the transaction context also seems to be a
weird way to determine whether the results are managed or not. Since
application servers use a transaction scope context I would think that
according to the spec you should be getting detached objects. I copied
some additional email addresses, maybe they will know if it's poor
wording or a Toplink feature.
-Matthieu Heimer
joel_at_exitcertified.com wrote:
> Hi Matt,
>
> Thanks for the prompt reply, but this part of the spec does not
> seem compatible with the test I ran.
>
> I ran a query. The method in question had NO transction annotation,
> so I assume it ran with a REQUIRED attribute. I invoked a set method
> on the object I received from the query and DID NOT invoke a merge.
> When I later queried the database, the record had been altered with
> the value I passed to the set method.
>
> How is that possible if I am getting back a detached object?
>
> Thanks,
> Joel
>
>
>> Page 68 of the persistence spec.
>>
>> Query methods other than the executeUpdate method are not required to be
>> invoked within a transaction
>> context. In particular, the getResultList and getSingleResult methods
>> are not
>> required to be invoked within a transaction context. If an entity
>> manager with transaction-scoped persistence
>> context is in use, the resulting entities will be detached; if an entity
>> manager with an extended persistence
>> context is used, they will be managed.
>>
>> joel_at_exitcertified.com wrote:
>>
>>> I have looked in the spec, but have not found any claim
>>> indicating whether a query returns a managed or unmanaged
>>> object.
>>>
>>> 1. Is it in the spec?
>>> 2. If so where.
>>>
>>> So I did an experiment, the result of which indicates
>>> that at least for the Sun App server, a query returns
>>> a managed object. (I Invoked a set method on the object
>>> returned from the query, without invoking merge. The
>>> database was updated.)
>>>
>>> If this is indeed the default behavior, the next question
>>> is why is the default behavior to return a managed entity?
>>> What is the benefit of a having queries return managed
>>> objects if:
>>>
>>> 1. Managing objects is more expensive than not managing them.
>>> 2. Most queries read, but do not write data.
>>>
>>> Of course, my assumptions may be wrong. Maybe it's not that
>>> much more expensive to return a managed object than an
>>> unmanaged object. Maybe most queries write data rather than
>>> read data.
>>>
>>> Curious to know.
>>> Thanks,
>>> Joel
>>>
>>>
>>>
>>>
>
>