Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Reply-To: <msegel@segel.com>
From: "Michael Segel" <msegel@segel.com>
To: "'Derby Discussion'" <derby-user@db.apache.org>
Subject: RE: ClassFormatError while performing a SQL insert
Date: Thu, 7 Sep 2006 14:03:11 -0500
Organization: MSCC
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <450065E6.2060902@apache.org>
Thread-Index: AcbSrRdgewck2JumTgudJJMNFFIyTQAAZdjA
Message-Id: <20060907190823.01E412C044@dbrack01.segel.com>

Outch. Missed the first part of Derby's statement.

Ok.

Doesn't make sense though. 
His insert is a batch insert? 
Imagine if you had a table where you were inserting a record that was larger
than 64KB. (Not including blobs) Are you saying that Derby would have failed
prior to your fix?

Within the limitations of Derby and (Java), Leslie's app design doesn't make
sense to begin with.


> -----Original Message-----
> From: Daniel John Debrunner [mailto:djd@apache.org]
> Sent: Thursday, September 07, 2006 1:33 PM
> To: Derby Discussion
> Subject: Re: ClassFormatError while performing a SQL insert
> 
> derby@segel.com wrote:
> 
> > But his issue isn't with Derby.
> >
> > He'd have the same problem with any Java app and a JDBC connection.
> > We know this because Leslie wrote that if he inserted just a subset of
> his
> > data, it would work. ;-)
> 
> Nope, the error Leslie reported is for a class generated by Derby:
> 
> Leslie's error:
> > org.apache.derby.exe.ac08264012x010dx8870x7dfdx0000000be0501 to file
> ac08264012x010dx8870x7dfdx0000000be0501.class.
> >java.lang.ClassFormatError: Invalid method Code length 69936 in class
> file
> > org/apache/derby/exe/ac08264012x010dx8870x7dfdx0000000be0501
> 
> The problem is that with a large SQL INSERT statement with many rows,
> all values as literals the generated class size is a factor of the
> number of rows. Reducing the number of rows reduces the generated
> method's size and hence it works, increasing the number of rows
> increases the method's size beyond the 64k limit. Changes in 10.2 allow
> the generated code to be split over many methods, working around the
> per-method limit.
> 
> If it was an issue due to his application class being too big, it would
> have failed when he compiled it, not at run time.
> 
> But hey what do I know, I just spent six months fixing the very issue
> that Leslie is running into. :-)
> 
> Dan.