You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cayenne.apache.org by "Andrus Adamchik (JIRA)" <ji...@apache.org> on 2013/06/22 21:54:20 UTC

[jira] [Closed] (CAY-1682) Remove EntityResolver synchronizations

     [ https://issues.apache.org/jira/browse/CAY-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrus Adamchik closed CAY-1682.
--------------------------------

    Resolution: Won't Fix

over-synchronization was removed per CAY-1789 . the other points are still valid, but we won't be keeping a jira for that until we actually want to work on it.
                
> Remove EntityResolver synchronizations
> --------------------------------------
>
>                 Key: CAY-1682
>                 URL: https://issues.apache.org/jira/browse/CAY-1682
>             Project: Cayenne
>          Issue Type: Improvement
>          Components: Core Library
>    Affects Versions: 3.1M3
>         Environment: This affects all versions of Cayenne. The fix should go either in 3.1 or 3.2
>            Reporter: Andrus Adamchik
>            Assignee: Andrus Adamchik
>
> EntityResolver contents normally don't change in runtime, yet it has a bunch of synchronized methods - lookupObjEntity, getClassDescriptor(), etc. (Surprisingly 'getObj/DbEntity' is not synchronized). All these methods are invoked very frequently and create contention points in highly concurrent apps. IIRC historically these methods were added for the benefit of the Modeler (as a user might add/remove DataMaps, and change their contents all the time).
> The goal of this task is to provide a simple and efficient EntityResolver for the runtime. 
> However it may require deep refactoring which may push it to 3.2 release. Specifically:
> 1. Split the uses of EntityResolver between the Modeler and runtime (it is generally easy based on MappingNamespace interface, except when we are calling EJBQL validation API that requires EntityResolver)
> 2. Prevent DataMap from looking for objects in the parent namespace. This is confusing and was probably done for the modeler benefit too.
> 3. Remove DataMap change events (probably will require a special DataMap implementation for the Modeler that has those events)
> 4. Remove EntityResolver on-demand compilation features. If a user wants to change the mapping dynamically, it is probably safer and more efficient to create a new EntityResolver from scratch.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira