Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Message-ID: <169790791.1221756404287.JavaMail.jira@brutus>
Date: Thu, 18 Sep 2008 09:46:44 -0700 (PDT)
From: "Michael Dick (JIRA)" <jira@apache.org>
To: dev@openjpa.apache.org
Subject: [jira] Closed: (OPENJPA-180) Batch Update support needed for
 OpenJPA performance
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Michael Dick closed OPENJPA-180.
--------------------------------

    Resolution: Fixed

This issue was fixed under OPENJPA-464 (if not before then). 

> Batch Update support needed for OpenJPA performance
> ---------------------------------------------------
>
>                 Key: OPENJPA-180
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-180
>             Project: OpenJPA
>          Issue Type: Bug
>    Affects Versions: 0.9.0, 0.9.6, 0.9.7, 1.0.0, 1.1.0
>         Environment: All
>            Reporter: John Stecher
>
> After doing some more performance testing on OpenJPA using a variety of primitive benchmarks I have noticed that it lags competitors significantly in performance in scenarios that stress multiple updates inside of a single transaction.  Obviously almost every application server out there today overcomes this by implementing some sort of batch update feature and I would almost consider it a bug that OpenJPA does not have this support as it appears that Hibernate and Toplink both do as do most J2EE vendors CMP 2.X containers.
> I would say that the ramifications of not shipping batch update support would be fairly huge from both a JPA performance perspective but also from the more costly backend database perspective where typically CPU cycles are far more limited than on the application server machine.  Looking at most complex applications in the market place today and realizing almost all of them need this support to some degree I want this JIRA to drive that feature into OpenJPA.  Given the fact so many legacy containers and persistence engines have support for it, I consider it a bug that OpenJPA does not have it already.
> Always open for thoughts.  Just started looking at this so I am not sure if it has been brought up in the past but does anyone have ideas or implementation prototypes that we could work together to build? 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.