openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: why do we save all the exceptions during flush??
Date Mon, 27 Aug 2007 17:08:02 GMT
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 <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

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!


Mime
View raw message