You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Teresa Kan <tc...@gmail.com> on 2007/08/22 23:08:14 UTC
why do we save all the exceptions during flush??
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
Re: why do we save all the exceptions during flush??
Posted by Craig L Russell <Cr...@Sun.COM>.
FWIW, I agree with Patrick that the current behavior is reasonable.
In the particular case mentioned, it's not obvious to me that it's
even possible to predict the outcome of 99 future inserts simply
because the first insert caused a constraint violation.
This isn't a development time issue. Even (especially) in production,
it's critical that the entire story of why a transaction fails be
preserved for analysis. Problems in production systems are
notoriously difficult to track down, and the more information we can
provide, the better.
Craig
On Aug 23, 2007, at 12:50 PM, Patrick Linskey wrote:
>> 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 <tc...@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 <pl...@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 <tc...@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
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: why do we save all the exceptions during flush??
Posted by Patrick Linskey <pl...@gmail.com>.
> 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 <tc...@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 <pl...@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 <tc...@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
Re: why do we save all the exceptions during flush??
Posted by Teresa Kan <tc...@gmail.com>.
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 <pl...@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 <tc...@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
>
Re: why do we save all the exceptions during flush??
Posted by Patrick Linskey <pl...@gmail.com>.
> 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 <tc...@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