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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 >
