Hi,
Setting a batchLimit to -1 indicates there is no limit. Normally, this
would not be good since you could run into "out of resources" (memory,
connections, locks, etc) type situation. So, I wouldn't suggest running
with batchLimit set to -1 for any database. Setting it to 0 turns it off.
By default, we set batchLimit to 100 for DB2 and Oracle. I can't remember
which database you are using, but maybe you could try running with a
batchLimit of 100. Depending on your application, running with statement
batching may help with performance.
Kevin
On Mon, Feb 2, 2009 at 3:58 AM, is_maximum <mnr...@gmail.com> wrote:
>
> Hi Fay,
> I've just found that all the problems have raised from 'batchLimit=-1'
>
> if I set it to 0 everything work fine. now the weird optimistic exception
> and that jvm error have gone.
>
> So I think we can't think of this feature (batch statements). do you have
> any idea?
>
>
>
> Fay Wang wrote:
> >
> > Hi,
> >
> > Sometimes the OptimisticLockException is thrown because of the
> > SQLException during insert. Could you turn on the trace and send us the
> > log file?
> >
> > <property name="openjpa.Log"
> > value="File=c:\\trace.log,DefaultLevel=TRACE"/>
> >
> > Regards,
> > Fay
> >
> >
> >
> >
> >
> > --- On Sun, 2/1/09, is_maximum <mnr...@gmail.com> wrote:
> >
> >> From: is_maximum <mnr...@gmail.com>
> >> Subject: Re: [URGENT] performance issues
> >> To: users@openjpa.apache.org
> >> Date: Sunday, February 1, 2009, 10:33 PM
> >> Hi Kevin,
> >> Sorry for replying late, I was facing a rush of work.
> >>
> >> Well we didn't change the OpenJPA version we still use
> >> 1.2.0 version and we
> >> still experiencing the same damned
> >> OptimisticLockException!!!
> >>
> >> Since I have changed these configuration the system
> >> responses weired.
> >>
> >> I have an entity say Entry with a one-to-many relationship
> >> with Category.
> >> when a new entry is coming I persist them like this:
> >>
> >> dao.save(entry);
> >> for (Category c : entry.getCategories()){
> >> //do some work on categories here
> >> c.setEntry(entry);
> >> dao.save(c);
> >> }
> >>
> >>
> >> this snippet code were working fine before but after
> >> changing the batchLimit
> >> to -1 it won't work at all and a fatal error will be
> >> thrown:
> >>
> >> JDWP exit error JVMTI_ERROR_WRONG_PHASE(112): on getting
> >> class status
> >> FATAL ERROR in native method: JDWP on getting class status,
> >> jvmtiError=JVMTI_ERROR_WRONG_PHASE(112)
> >>
> >>
> >> I don't know why this batch updating affect this simple
> >> insert statements.
> >> However I used OpenJPA 2.0 Snapshot to see if this error
> >> has been cleared
> >> but in that version still we have problem. By the way,
> >> because we have used
> >> the word 'entry' in our JPQL currently we decided
> >> not to use version 2,0
> >> because this is a reserved word in this version! You see
> >> there are lots of
> >> problems just right when we are going to close the
> >> project!!!
> >>
> >> Do you have any idea on removing optimistic locking
> >> exception? because this
> >> is a big deal right now and if we couldn't remove it,
> >> that will kill us :)
> >>
> >> thanks
> >>
> >>
> >>
> >> Kevin Sutter wrote:
> >> >
> >> > On Thu, Jan 29, 2009 at 2:20 PM, is_maximum
> >> <mnr...@gmail.com> wrote:
> >> >
> >> >>
> >> >> I really don't know why after about 6 months
> >> working with OpenJPA and
> >> >> inserting near a million records we should face
> >> this problem? what have
> >> >> changed that cause optimistic locking to be
> >> activated spontaneously!!!
> >> >
> >> >
> >> > Hmmm... Not sure. What has changed in the last six
> >> months? That is,
> >> > what
> >> > version of OpenJPA did you start with and what version
> >> are you currently
> >> > running with? As you move from release to release,
> >> there are bound to be
> >> > changes. And, in some cases, the changes may actually
> >> have closed some
> >> > holes that you were accidentally avoiding. That is,
> >> maybe you were
> >> > "lucky"... :-)
> >> >
> >> > We do have quite an extensive test bucket and we do
> >> attempt to avoid any
> >> > type of regressions. But, our test bucket (like any
> >> other test bucket) is
> >> > not exhaustive. You could be exercising an area of
> >> code that just hasn't
> >> > been covered to the extent it should be. There are so
> >> many variables with
> >> > databases, configurations, jvms, environmental,
> >> openjpa, etc.
> >> >
> >> > If you can help identify and isolate the changes that
> >> caused your
> >> > concerns,
> >> > then maybe we can help out.
> >> >
> >> > Thanks,
> >> > Kevin
> >> >
> >> >
> >> >>
> >> >>
> >> >> Pinaki Poddar wrote:
> >> >> >
> >> >> > Hi,
> >> >> >> but using build-time enhancer. I tried
> >> ant-runner for maven but was
> >> >> >> unable to enhance my classes
> >> >> >> if I don't give any class name I get
> >> this message:
> >> >> >
> >> >> > A few minutes of digging with classpath
> >> and other beasts to enhance
> >> >> at
> >> >> > build-time will save you a lot of pain and
> >> gain performance. Enhancer
> >> >> > fails mostly with classpath issues and
> >> availability of
> >> >> > META-INF/persistence.xml etc.
> >> >> >
> >> >> > If you have access to OpenJPA source code,
> >> follow the trail at
> >> >> > ./openjpa-persistence-jdbc/pom.xml and
> >> >> >
> >> ./openjpa-persistence-jdbc/src/main/ant/enhancer.xml
> >> >> >
> >> >> > It shows one way to enhance 100's of
> >> Entity classes used for testing.
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> >> --
> >> >> View this message in context:
> >> >>
> >> http://n2.nabble.com/-URGENT--performance-issues-tp2232295p2241065.html
> >> >> Sent from the OpenJPA Users mailing list archive
> >> at Nabble.com.
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >> http://n2.nabble.com/-URGENT--performance-issues-tp2232295p2256731.html
> >> Sent from the OpenJPA Users mailing list archive at
> >> Nabble.com.
> >
> >
> >
> >
> >
>
> --
> View this message in context:
> http://n2.nabble.com/-URGENT--performance-issues-tp2232295p2257195.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
>
