openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Teresa Kan" <tck...@gmail.com>
Subject Re: why do we save all the exceptions during flush??
Date Thu, 23 Aug 2007 13:54:21 GMT
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
>

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