openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roytman, Alex" <>
Subject RE: Why would Kodo refuse to batch inserts in certain tables? Big performance drop migrating to Kodo 4.1
Date Tue, 17 Oct 2006 01:04:29 GMT

Attached is JDBC trace and my mapping file. 

You can see how everything but DOCUMENT_NODE is batched.

DOCUMENT_NODE is a super-class table. It has several sub-classes all but
one mapped on the same table. The one mapped vertically uses DOCUMENT
table. DOCUMENT_NODE have several bi- and uni-directional recursive

The rest of the classes are related to DOCUMENT_NODE via mapped-by


-----Original Message-----
From: Marc Prud'hommeaux [] On Behalf Of
Marc Prud'hommeaux
Sent: Monday, October 16, 2006 7:30 PM
Subject: Re: Why would Kodo refuse to batch inserts in certain tables?
Big performance drop migrating to Kodo 4.1


So you are saying that batching is working OK in general, just not  
for a particular class? And that this particular class was batching  
fine with previous versions? That is odd, although there are some  
cases where we might refuse to batch a particular class (because of a  
driver bug with batching certain column types, etc).

As a shot in the dark, we do work around a bug in the Oracle JDBC  
driver's failure to batch date/time effectively.

Can you post the SQL log that shows the series of SQL statements that  
should have been batched, but weren't? That might help shed light on it.

Also, database and JDBC driver type/version would be useful.

On Oct 15, 2006, at 7:30 PM, Roytman, Alex wrote:

> Hello,
> While migrating to Kodo 4.1 I noticed significant drop in insert
> performance. I trace it down to some strange batching behavior. While
> most of the PC were committed with batched inserts one particular  
> class
> refused to batch and would insert row by row resulting in 10 times
> performance drop.
> There is nothing special about the class. Its hierarchy is mapped on
> base its table except for one of the lowest members which is mapped
> vertically.
> Thank you very much
> Alex Roytman
> Peace Technology, Inc.
> 301-206-9696x103

  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message