openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <plins...@gmail.com>
Subject Re: why do we save all the exceptions during flush??
Date Thu, 23 Aug 2007 19:50:51 GMT
> Gathering more info about the exceptions are nice thing to do. However, it
> triggers lots of unnecessary execution since they will fail the same way. It
> would be nice to see the exception immediately, then correct the problem and
> continue on. Of course, most of these scenarios will be happened at
> development time, not in the real business runtime. The performance is not a
> big issue.

How much extra time is this costing you? Compare this to compilation;
I'd rather let the compiler do more work and report more problems,
rather than having to go through a source file one error at a time.

-Patrick

On 8/23/07, Teresa Kan <tckan1@gmail.com> wrote:
> Patrick,
> Thanks for the explanation!
> Gathering more info about the exceptions are nice thing to do. However, it
> triggers lots of unnecessary execution since they will fail the same way. It
> would be nice to see the exception immediately, then correct the problem and
> continue on. Of course, most of these scenarios will be happened at
> development time, not in the real business runtime. The performance is not a
> big issue.
> Will it be helpful if we can provide a property to gather the exceptions as
> user wants? By default, we can just throw the exception whenever it occurs.
> During the development time, if user wants to gather more info, then he/she
> can enable the property to see more exceptions. I don't have a strong
> opinion about the default value.. Use the current behavior as default is
> fine too.
> Any comment?
>
> Thanks
> Teresa
>
>
>
>
> On 8/22/07, Patrick Linskey <plinskey@gmail.com> wrote:
> >
> > > Currently I have 100 insertions, each has a constraint violation.
> > > Instead of stopping the  processing of the insertion once an exception
> > was
> > > encountered, all 100 insertions were executed. Then 100 exceptions were
> > > thrown at the end of process. Will it waste the time to continue to
> > execute
> > > the statement once an exception occurs?
> >
> > The nice thing about gathering all the exceptions is that the user is
> > presented with more information about what went wrong. So, you know
> > that all 100 records had problems, not just one of them.
> >
> > Clearly, this will take additional time. However, the proverbial ship
> > is sinking at this point anyways, so performance isn't really the
> > concern. If a system has lots of these failures happening at the same
> > time, that will be bad for the overall throughput, but that's
> > definitely not the expected case.
> >
> > Is the exception-gathering behavior causing problems for you?
> >
> > -Patrick
> >
> > On 8/22/07, Teresa Kan <tckan1@gmail.com> wrote:
> > >  What are the rules to handle the exception?
> > > I found out that in the OperationOrderUpdateManager.flush (rowMgr,
> > psMgr,
> > > exceps), it always flushed all the primary rows first, then flush any
> > > constraintUpdates, then the secondary rows. In each set of flush, it
> > saved
> > > all the exceptions. If any exception in the primary rows, should we
> > rollback
> > > the transaction instead of continue to the next flush?
> > > I don't see the logic closely enough that will handle the exception and
> > > retry if there is any constraint violation. So if one table has the
> > > exception, should we throw the exception? What scenario that will cause
> > the
> > > first exception be ignored ? I also discovered that the exception
> > eventually
> > > be threw back and failed at the end.
> > >
> > > Currently I have 100 insertions, each has a constraint violation.
> > > Instead of stopping the  processing of the insertion once an exception
> > was
> > > encountered, all 100 insertions were executed. Then 100 exceptions were
> > > thrown at the end of process. Will it waste the time to continue to
> > execute
> > > the statement once an exception occurs?
> > >
> > > Please clarify and thanks,
> > >
> > > Teresa
> > >
> >
> >
> > --
> > Patrick Linskey
> > 202 669 5907
> >
>


-- 
Patrick Linskey
202 669 5907

Mime
View raw message