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 andcontinue on. Of course, most of these scenarios will be happened atdevelopment time, not in the real business runtime. The performance is not abig 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 <[EMAIL PROTECTED]> 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 andcontinue on. Of course, most of these scenarios will be happened atdevelopment time, not in the real business runtime. The performance is not abig 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/shecan enable the property to see more exceptions. I don't have a strongopinion about the default value.. Use the current behavior as default isfine 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 exceptionwasencountered, all 100 insertions were executed. Then 100 exceptions werethrown at the end of process. Will it waste the time to continue toexecutethe statement once an exception occurs?The nice thing about gathering all the exceptions is that the user ispresented 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 shipis sinking at this point anyways, so performance isn't really theconcern. If a system has lots of these failures happening at the sametime, 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, itsavedall the exceptions. If any exception in the primary rows, should werollbackthe transaction instead of continue to the next flush?I don't see the logic closely enough that will handle the exception andretry if there is any constraint violation. So if one table has theexception, should we throw the exception? What scenario that will causethefirst exception be ignored ? I also discovered that the exceptioneventuallybe 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 exceptionwasencountered, all 100 insertions were executed. Then 100 exceptions werethrown at the end of process. Will it waste the time to continue toexecutethe 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:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
