You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by David Wisneski <wi...@gmail.com> on 2007/01/11 02:11:08 UTC
sql statement batching
Does OpenJPA support sql batching (i.e. the jdbc addBatch api on a
prepared Statement)? The user's guide shows how to set the addBatch
limit, but it does not work. It would appear that if there was code
to do this it was removed.
I think that most ORM runtimes support this feature and we will be at
a competitive disadvantage with Hibernate and TopLink without it. It
is very important when creating and persist many new object of the
same type in one transaction (i.e. persisting 1000 new Customer beans)
or doing many updates ( updating the salary on 1000 Employee beans).
I know that addBatch performance vs. doing multiple jdbc executeUpdate
makes a big differrent in DB2 -- and I would assume also other
databases.
If the code was there and removed -- any thoughts about adding it
back in? Otherwise we would most likely have to develop it for our
enterprise customer.
Re: sql statement batching
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Kevin,
I agree that sql batching is such a huge performance win that most
real users would want this feature.
Craig
On Jan 15, 2007, at 6:39 AM, Kevin Sutter wrote:
> Marc,
> Concerning the infrastructure for sql batching support... Do you
> mean that
> this support is pluggable into the OpenJPA runtime? That is, is
> there a
> pluggable interface for other vendors to provide support for sql
> batching?
> Or, is it just that the runtime could be updated to support sql
> batching
> (and then the source would be out of synch with the OpenJPA
> repository)?
>
> I'm just trying to assess the impact for this "removed" function.
> If each
> vendor that incorporates OpenJPA needs to modify their version of the
> runtime to provide sql batching support (and it's a common
> feature), then
> the consistency of OpenJPA will be impacted.
>
> From Dave's note, it seems like we have a mistake in the user's
> guide (at a
> minimum). But, even if the "addBatch limit" is taken out of the
> user's
> guide, then as each vendor adds this support back in (for performance
> reasons), the configuration of this feature may also vary from one
> vendor to
> the next.
>
> I'm still trying to gather some "real data" to demonstrate the
> performance
> advantages of sql batching (or lack there of). But, if Dave's
> comments are
> accurate, then maybe we need to consider re-introducing the sql
> batching
> support. Not only for performance reasons, but also for runtime and
> configuration consistency reasons.
>
> My two cents worth... :-)
>
> Kevin
>
> On 1/11/07, Marc Prud'hommeaux <mp...@apache.org> wrote:
>>
>> David-
>>
>> Batching functionality was not included in the OpenJPA code
>> contribution made by BEA, but you are correct that the infrastructure
>> necessary for its support is in place.
>>
>> I can't comment on whether BEA could be persuaded to contribute that
>> code as well beyond saying that they are always open to community
>> suggestions and feedback.
>>
>>
>>
>> On Jan 10, 2007, at 5:11 PM, David Wisneski wrote:
>>
>> > Does OpenJPA support sql batching (i.e. the jdbc addBatch api on a
>> > prepared Statement)? The user's guide shows how to set the
>> addBatch
>> > limit, but it does not work. It would appear that if there was
>> code
>> > to do this it was removed.
>> >
>> > I think that most ORM runtimes support this feature and we will
>> be at
>> > a competitive disadvantage with Hibernate and TopLink without
>> it. It
>> > is very important when creating and persist many new object of the
>> > same type in one transaction (i.e. persisting 1000 new Customer
>> beans)
>> > or doing many updates ( updating the salary on 1000 Employee
>> beans).
>> > I know that addBatch performance vs. doing multiple jdbc
>> executeUpdate
>> > makes a big differrent in DB2 -- and I would assume also other
>> > databases.
>> >
>> > If the code was there and removed -- any thoughts about adding it
>> > back in? Otherwise we would most likely have to develop it for our
>> > enterprise customer.
>>
>>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: sql statement batching
Posted by Marc Prud'hommeaux <mp...@apache.org>.
Kevin-
On Jan 15, 2007, at 6:39 AM, Kevin Sutter wrote:
> Marc,
> Concerning the infrastructure for sql batching support... Do you
> mean that
> this support is pluggable into the OpenJPA runtime? That is, is
> there a
> pluggable interface for other vendors to provide support for sql
> batching?
> Or, is it just that the runtime could be updated to support sql
> batching
> (and then the source would be out of synch with the OpenJPA
> repository)?
The former. Kodo is built on top of OpenJPA with no source
modification or patches (using only the ProductDerivation framework).
Without going into too many details about the actual implementation,
it is mostly done using subclasses of the PreparedStatementManager
and OperationOrderUpdateManager.
> I'm just trying to assess the impact for this "removed" function.
> If each
> vendor that incorporates OpenJPA needs to modify their version of the
> runtime to provide sql batching support (and it's a common
> feature), then
> the consistency of OpenJPA will be impacted.
I sympathize with that concern. All I can really say is that the
holdbacks to the OpenJPA contributions were carefully considered to
maximize functionality rather than performance.
> From Dave's note, it seems like we have a mistake in the user's
> guide (at a
> minimum). But, even if the "addBatch limit" is taken out of the
> user's
> guide, then as each vendor adds this support back in (for performance
> reasons), the configuration of this feature may also vary from one
> vendor to
> the next.
It is indeed a mistake in the documentation. It should be removed.
The exact configuration property may vary from vendor to vendor.
> I'm still trying to gather some "real data" to demonstrate the
> performance
> advantages of sql batching (or lack there of). But, if Dave's
> comments are
> accurate, then maybe we need to consider re-introducing the sql
> batching
> support. Not only for performance reasons, but also for runtime and
> configuration consistency reasons.
Clearly it would be simplest and most beneficial if the code for
batching was added to the contribution. I can't really comment on the
likelihood of whether that will ever happen or not, but I agree that
it would be nice.
> My two cents worth... :-)
>
> Kevin
>
> On 1/11/07, Marc Prud'hommeaux <mp...@apache.org> wrote:
>>
>> David-
>>
>> Batching functionality was not included in the OpenJPA code
>> contribution made by BEA, but you are correct that the infrastructure
>> necessary for its support is in place.
>>
>> I can't comment on whether BEA could be persuaded to contribute that
>> code as well beyond saying that they are always open to community
>> suggestions and feedback.
>>
>>
>>
>> On Jan 10, 2007, at 5:11 PM, David Wisneski wrote:
>>
>> > Does OpenJPA support sql batching (i.e. the jdbc addBatch api on a
>> > prepared Statement)? The user's guide shows how to set the
>> addBatch
>> > limit, but it does not work. It would appear that if there was
>> code
>> > to do this it was removed.
>> >
>> > I think that most ORM runtimes support this feature and we will
>> be at
>> > a competitive disadvantage with Hibernate and TopLink without
>> it. It
>> > is very important when creating and persist many new object of the
>> > same type in one transaction (i.e. persisting 1000 new Customer
>> beans)
>> > or doing many updates ( updating the salary on 1000 Employee
>> beans).
>> > I know that addBatch performance vs. doing multiple jdbc
>> executeUpdate
>> > makes a big differrent in DB2 -- and I would assume also other
>> > databases.
>> >
>> > If the code was there and removed -- any thoughts about adding it
>> > back in? Otherwise we would most likely have to develop it for our
>> > enterprise customer.
>>
>>
Re: sql statement batching
Posted by Kevin Sutter <kw...@gmail.com>.
Marc,
Concerning the infrastructure for sql batching support... Do you mean that
this support is pluggable into the OpenJPA runtime? That is, is there a
pluggable interface for other vendors to provide support for sql batching?
Or, is it just that the runtime could be updated to support sql batching
(and then the source would be out of synch with the OpenJPA repository)?
I'm just trying to assess the impact for this "removed" function. If each
vendor that incorporates OpenJPA needs to modify their version of the
runtime to provide sql batching support (and it's a common feature), then
the consistency of OpenJPA will be impacted.
>From Dave's note, it seems like we have a mistake in the user's guide (at a
minimum). But, even if the "addBatch limit" is taken out of the user's
guide, then as each vendor adds this support back in (for performance
reasons), the configuration of this feature may also vary from one vendor to
the next.
I'm still trying to gather some "real data" to demonstrate the performance
advantages of sql batching (or lack there of). But, if Dave's comments are
accurate, then maybe we need to consider re-introducing the sql batching
support. Not only for performance reasons, but also for runtime and
configuration consistency reasons.
My two cents worth... :-)
Kevin
On 1/11/07, Marc Prud'hommeaux <mp...@apache.org> wrote:
>
> David-
>
> Batching functionality was not included in the OpenJPA code
> contribution made by BEA, but you are correct that the infrastructure
> necessary for its support is in place.
>
> I can't comment on whether BEA could be persuaded to contribute that
> code as well beyond saying that they are always open to community
> suggestions and feedback.
>
>
>
> On Jan 10, 2007, at 5:11 PM, David Wisneski wrote:
>
> > Does OpenJPA support sql batching (i.e. the jdbc addBatch api on a
> > prepared Statement)? The user's guide shows how to set the addBatch
> > limit, but it does not work. It would appear that if there was code
> > to do this it was removed.
> >
> > I think that most ORM runtimes support this feature and we will be at
> > a competitive disadvantage with Hibernate and TopLink without it. It
> > is very important when creating and persist many new object of the
> > same type in one transaction (i.e. persisting 1000 new Customer beans)
> > or doing many updates ( updating the salary on 1000 Employee beans).
> > I know that addBatch performance vs. doing multiple jdbc executeUpdate
> > makes a big differrent in DB2 -- and I would assume also other
> > databases.
> >
> > If the code was there and removed -- any thoughts about adding it
> > back in? Otherwise we would most likely have to develop it for our
> > enterprise customer.
>
>
Re: sql statement batching
Posted by Marc Prud'hommeaux <mp...@apache.org>.
David-
Batching functionality was not included in the OpenJPA code
contribution made by BEA, but you are correct that the infrastructure
necessary for its support is in place.
I can't comment on whether BEA could be persuaded to contribute that
code as well beyond saying that they are always open to community
suggestions and feedback.
On Jan 10, 2007, at 5:11 PM, David Wisneski wrote:
> Does OpenJPA support sql batching (i.e. the jdbc addBatch api on a
> prepared Statement)? The user's guide shows how to set the addBatch
> limit, but it does not work. It would appear that if there was code
> to do this it was removed.
>
> I think that most ORM runtimes support this feature and we will be at
> a competitive disadvantage with Hibernate and TopLink without it. It
> is very important when creating and persist many new object of the
> same type in one transaction (i.e. persisting 1000 new Customer beans)
> or doing many updates ( updating the salary on 1000 Employee beans).
> I know that addBatch performance vs. doing multiple jdbc executeUpdate
> makes a big differrent in DB2 -- and I would assume also other
> databases.
>
> If the code was there and removed -- any thoughts about adding it
> back in? Otherwise we would most likely have to develop it for our
> enterprise customer.