[GLASSFISH-413] Need to improve DISTINCT EJBQL processing Created: 15/Mar/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Improvement Priority: Critical
Reporter: gyorke Assignee: gyorke
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 413

 Description   

A solution for JPQL DISTINCT was implemented but a full analysis anf resolution
was not completed at the time. JPQL DISTINCT support should be readdressed
providing a thorough and more performant solution



 Comments   
Comment by marina vatkina [ 15/Mar/06 ]

Need more info

Comment by gyorke [ 16/Mar/06 ]

Code elements with tag: GF_ISSUE_395 should be re-evaluated as part of this bug.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-3985] Support for WeakReferences in Entity Manager in TopLink essentias Created: 08/Jan/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Task Priority: Major
Reporter: abien Assignee: gyorke
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File feedback.zip     Zip Archive TopLinkEssentialsWeakTest.zip     Text File TopLinkEssentialsWeakTest.zip     Text File toplink_modification.zip     Text File toplink_modification_II.zip    
Issuezilla Id: 3,985

 Description   

This issue was discussed already in the persistence@glassfish.dev.java.net.

Short Description:

The EntityManager holds all JPA-entities in hits internal cache with "hard
references", which causes Memory Leaks in stateful environment, where the
Entities remain persistent between transactions (e.g. Netbeans RCP, Eclipse RCP
clients, Seam, or frameworks with Context.Extended).

The attached patch (all modified classes, from yesterdays head), consists all
classes and modifications, and makes TopLink configurable.



 Comments   
Comment by abien [ 08/Jan/08 ]

Created an attachment (id=1297)
Modified classes (according to the explanation of Gordon Yorke)

Comment by abien [ 08/Jan/08 ]

Created an attachment (id=1298)
Simple Unit Tests, which just verifies, whether thie configuration is working

Comment by gyorke [ 08/Jan/08 ]

Changing subcomponent.

Comment by gyorke [ 15/Jan/08 ]

The UnitOfWork (Persistence Context) is more than a first level cache and that
should be reflected in the property name. Otherwise the property may be used
without an appreciation for the hard to detect side-effect of change loss. The
property should be moved to the config package with the other properties as we
will want customers to be able to browse the javaDocs and see these properties
as an option.
In the UnitOfWork the deletedObjects should not be touched as a deleted
object will probably be dereferenced by the client and may be lost if garbage
collected. The 'newAggregates' list should also have weak references in the
case the parent of an embeddable object is released.
Private visibility is generally not used in TopLink code for class
attributes. Protected provides similar restrictions but does not restrict
extension through subclassing which has been quite useful in the past.
With the IdentityHashtable it is the keys that should be weak in most
cases.with the newObjectsOriginalToClone both the key and the value should be
weak. Also for performance reasons it would be better to have the weak
IdentityHashtable be a subclass. That way the Hashtable code will remain
micro-optimized. At some point in V3 there is a plan to migrate to the JDK
collections and having a separate type will make that easier.
The IdentityMapManager.buildNewIdentityMap() will need to be updated as well.

Comment by gyorke [ 15/Jan/08 ]

Created an attachment (id=1307)
feedback

Comment by abien [ 22/Jan/08 ]

Created an attachment (id=1310)
Further modifications (according to the comment of Gordon York)

Comment by abien [ 22/Jan/08 ]

1. Property renamed to: toplink.persistence.context.reference.mode
2. In UnitOfWork the deleteObjects is untouched - it uses the "hard references"
3. newAggregates uses now WeakKeyIdentityHashtable (with weak keys, and hard values)
4. The referenceMode reference was changed from private to protected
5. IdentityHashtable is abstract now. HardIdentityHashtable,
WeakKeyIdentityHashtable and WeakKeyAndValueIdentityHashtable inherit from it.
However, because each hashtable accesses the Entries directly I just replicated
the code to the subclasses. Each of the Hashtable accesses the Entry either
directly , or using the WeakReference (then with accessors).
6. newObjectsOriginalToClone is realized with weak keys and values.
7. The implementation of the method buildIdentityMap in the IdentityMapManager
was reused from Gordon's code.
8. I'm not sure whether in the class InheritancePolicy always the Hashtable with
the hard references has to be used:

public SQLSelectStatement
buildClassIndicatorSelectStatement(ObjectLevelReadQuery query) {
// ...
// 2612538 - the default size of HardIdentityHashtable (32) is appropriate
//Hard, or potentially Weak?
HardIdentityHashtable clonedExpressions = new HardIdentityHashtable();
9. Because IdentityHashtable is abstract now, I had to changed some additional
classes to instantiate the HardIdentityHashtable instead.
10. The basic test was extended with identity assertions.

Comment by abien [ 24/Jan/08 ]

Extended tests provided (identity assurance with weak settings)

Comment by abien [ 24/Jan/08 ]

Created an attachment (id=1312)
Unit Test (update)

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





Generated at Sun Aug 28 08:21:27 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.