Mailing-List: contact issues-help@ambari.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ambari.apache.org
Date: Wed, 4 Jan 2017 21:54:58 +0000 (UTC)
From: "Jonathan Hurley (JIRA)" <jira@apache.org>
To: issues@ambari.apache.org
Message-ID: <JIRA.13032008.1483547953000.643413.1483566898535@Atlassian.JIRA>
In-Reply-To: <JIRA.13032008.1483547953000@Atlassian.JIRA>
References: <JIRA.13032008.1483547953000@Atlassian.JIRA> <JIRA.13032008.1483547953667@arcas>
Subject: [jira] [Updated] (AMBARI-19364) Investigate Changing the Default
 Container Policy in JPA From Vector to ArrayList
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 04 Jan 2017 21:55:00 -0000


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

Jonathan Hurley updated AMBARI-19364:
-------------------------------------
    Fix Version/s:     (was: 2.5.0)
                   trunk

> Investigate Changing the Default Container Policy in JPA From Vector to ArrayList
> ---------------------------------------------------------------------------------
>
>                 Key: AMBARI-19364
>                 URL: https://issues.apache.org/jira/browse/AMBARI-19364
>             Project: Ambari
>          Issue Type: Task
>          Components: ambari-server
>    Affects Versions: trunk
>            Reporter: Jonathan Hurley
>            Assignee: Jonathan Hurley
>             Fix For: trunk
>
>         Attachments: AMBARI-19364.patch
>
>
> Recently I noticed that collections coming back from JPA were using a {{Vector}} as their concrete collection. This seems very wrong as {{Vector}} is a completely synchronized collection. 
> Tracing through EclipseLink, it seems like this really only affects [ReadAllQuery|http://grepcode.com/file/repo1.maven.org/maven2/org.eclipse.persistence/eclipselink/2.5.2/org/eclipse/persistence/queries/ReadAllQuery.java/#68]. Essentially, EclipseLink uses  a [ContainerPolicy|http://grepcode.com/file/repo1.maven.org/maven2/org.eclipse.persistence/eclipselink/2.5.2/org/eclipse/persistence/internal/queries/ContainerPolicy.java#ContainerPolicy] to determine how the result set should be collected. There are policies for {{Vector}}, {{ArrayList}}, {{HashSet}}, etc. 
> The interesting part here is that this really only affects the {{ReadAllQuery}} which is used by JPA's {{Query#getResultList()}} ... anytime it needs to create a collection of entities, it's going to use a {{Vector}}.
> There's actually very little documentation on this. In fact, the only way to change this is either set a global value for the default container policy, or set a per-query policy. An example of setting the global policy would be:
> {code}
> public class EclipseLinkSessionCustomizer implements SessionCustomizer {
>   /**
>    * {@inheritDoc}
>    * <p/>
>    * This class exists for quick customization purposes.
>    */
>   @Override
>   public void customize(Session session) throws Exception {
>     // ensure db behavior is same as shared cache
>     DatabaseLogin databaseLogin = (DatabaseLogin) session.getDatasourceLogin();
>     databaseLogin.setTransactionIsolation(DatabaseLogin.TRANSACTION_READ_COMMITTED);
>     // for some reason, read-all queries use a Vector as their container for
>     // result items - this seems like an unnecessary performance hit since
>     // Vectors are synchronized and there's no apparent reason to provide a
>     // thread-safe collection on a read all query
>     ContainerPolicy.setDefaultContainerClass(CoreClassConstants.ArrayList_class);
>   }
> }
> {code}
> This indeed causes collections returned by queries to be backed by ArrayLists. 
> There is some discussion on this topic already:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=255634
> It seems like this was kept as a {{Vector}} purely for backward compatibility reasons. 


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)