Hi Martin,
I should have also added that although TopLink Essentials is initially
focused on JPA implementation, we intend to continue to evolve and
enhance the product to add functionality the community requires
including features you see in Oracle TopLink that are not yet in TopLink
Essentials. We'd be very interested in hearing what features you deem
important and would like to see added.
-Tom
Tom Ware wrote:
>Hi Martin,
>
> Wonsoek has covered things fairly well.
>
> Take a look at the following link for the differences between TopLink
>Essentials and TopLink:
>
>http://www.oracle.com/technology/products/ias/toplink/jpa/resources/faq.html#13
>
>-Tom
>
>Wonseok Kim wrote:
>
>
>
>>Hi, Martin
>>Some replies in inline...
>>
>>On 11/22/06, *Martin Bayly* <mbayly_at_telus.net
>><mailto:mbayly_at_telus.net>> wrote:
>>
>> What is the relationship between the Oracle TopLink implementation and
>> the TopLink essentials that was donated to Glassfish?
>>
>>
>>I'm not Oracle guy, but as far I know commercial TopLink has more
>>functionalities such as distributed 2nd-level cache, query cache,
>>tools, non-RDB mappings, etc. Whereas TopLink Essentials is just
>>focusing on JPA implementation.
>>
>> Or put another way, are features like the SoftCacheWeakIdentityMap
>> described in the TopLink Cache Concepts documentation also available
>> within the Glassfish implementation (presumably with vendor specific
>> configurations)?
>>
>>
>>Yes, please see below.
>>http://www.oracle.com/technology/products/ias/toplink/jpa/resources/toplink-jpa-extensions.html
>>
>>
>> The background to this whole question is the ongoing debate about the
>> best way to use ORM solutions like JPA/TopLink/Hibernate in a single
>> tier rich client application - usually single user database.
>>
>> Some people believe a single application level session/entity
>> manager/persistence context is the best approach as it simplifies
>> having
>> long lived domain objects attached to user interface controls.
>>
>> However, this proved to be inappropriate with Hibernate as the
>> Hibernate
>> Session would just keep growing unless you specifically evicted
>> objects
>> that were no longer referenced by the UI which can be hard to track.
>>
>> So the alternative is to use a session/entity manager per interaction
>> which means you have to be able to reattach detached objects and
>> you may
>> end up with multiple references to the same object if you are not
>> careful (with Hibernate you also have to be careful about lazy loading
>> outside the session - though apparently not with TopLink).
>>
>> How does the Glassfish implementation handle objects in the
>> persistence
>> context? If you open an EntityManager session, will TopLink
>> essentials
>> hold onto any objects loaded into that persistence context until the
>> EntityManager is closed, or is it possible to set it up with a weak
>> reference identity mapping, so that if the application no longer
>> holds a
>> reference to these objects, they will be candidates for GC?
>>
>>
>>Weak type cache settings are applied only to 2nd-level cache but not
>>to persistence contexts. The persistence context should be maintained
>>until it is cleared or closed according to JPA spec. I think you'd
>>better maintain persistence contexts per transaction like Java
>>EE(container-managed) transaction-scoped EntityManager.
>>
>>Thanks,
>>-Wonseok
>>
>> Cheers
>> Martin
>>
>>
>>
>>
>
>
>
>