Announcement Announcement Module
Collapse
No announcement yet.
Need advice on exception handling approach Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Meaningful error messages?

    Hi Arno,

    I definitely understand what you mean with regards to the problems associated with maintaining the validation rules in the database and Java code. But my question is this: even if you do catch the DataIntegrityViolationException, how would you provide an informative error message to the user? What if a single entity, such as a User that is stored in the USER table, has multiple columns with unique constraints (such as USERNAME and EMAIL_ADDRESS)? How would you inform the user which field(s) he entered already exists in the database so that he can fix the problem?

    Maybe there is a way to inspect the DataIntegrityViolationException to determine the offending field(s), but can you provide a corresponding user-friendly error message to explain to the user?

    For this reason, it makes sense to me to enforce the rules during pre-insertion validation. As Colin mentioned, there is still a window in which data that passes this initial validation could still be rejected by the database. Maybe in those cases, a generic error could be reported to the user. But subsequent attempts would be caught during pre-insertion validation, and a meaningful error message could be provided.

    -Arthur Loder

    Comment


    • #17
      I thought I would use this topic as the subject of my first blog post!

      You can find it here if you are interested http://blog.interface21.com/main/200...my-first-post/

      Comment


      • #18
        Originally posted by tatvamasi
        Huh! so what the reason for having a middle tier (application layer)? I wonder if you can get done with having bunch of stored procedures and triggers doing job for ya'. Why do you need high profile language like java to do that? or why do you even need a middle tier to your application?

        ...Geez man I don't even understand why are you using Object Oriented technologies or a pattern oriented architecture or even a high profile framework like spring.
        Hi tatvamasi,
        You know who Rod Johnson is what his relations toward Spring framework. Let's see...
        J2EE developers (and Java developers in general) tend to hate stored procedures. There is some justification for this:

        Stored procedures aren't object-oriented. Readers familiar with Oracle will counter that Oracle 8.1.5 introduced Java stored procedures. However, they don't solve the O/R impedance mismatch as much as move it inside the database, and they don't foster truly object-oriented use of Java.

        Stored procedures aren't portable. Support for stored procedures varies much more than SQL dialects between RDBMSs. Nevertheless, it would be rare to lose the entire investment in a set of stored procedures on migrating from one RDBMS to another.

        If stored procedures grow complex, they may reduce an application's maintainability.

        Some other common objections have less validity:

        "Using stored procedures puts business logic in the wrong place"
        If we distinguish between persistence logic and business logic, the idea of putting persistence logic in a relational database makes perfect sense.

        "Using stored procedures means that J2EE security may be compromised"
        Security is a matter of business logic, not persistence logic: if we keep our business logic in J2EE, there is no need to restrict access to data.

        "The database will become a performance bottleneck"
        Especially, if a single database instance is serving a cluster of J2EE servers, the processing of stored procedures may limit overall performance. However, there are trade-offs to consider:

        In my experience, it's much commoner to see network performance between application server and database limit the overall performance of a J2EE application than the performance of a well-designed database.

        There's no reason to perform an operation in a stored procedure rather than a J2EE component unless the operation can be done more naturally and efficiently inside the database server than in Java. Thus if we've implemented an operation efficiently inside the RDBMS and it still eats the server's CPU, it probably indicates that the RDBMS is badly tuned or needs to run on better hardware. Performing the same heavily-requested operation less efficiently in the application server will probably result in a more severe problem, and the need for more additional hardware.

        The use of stored procedures from J2EE applications is an area where we should be pragmatic, and avoid rigid positions. I feel that many J2EE developers' blanket rejection of stored procedures is a mistake. There are clear benefits in using stored procedures to implement persistence logic in some situations:

        Stored procedures can handle updates spanning multiple database tables. Such updates are problematic with O/R mapping.

        A more general form of the first point) Stored procedures can be used to hide the details of the RDBMS schema from Java code. Often there's no reason that Java business objects should know the structure of the database.

        Round trips between the J2EE server and the database are likely to be slow. Using stored procedures can consolidate them in the same way in which we strive to consolidate remote calls in distributed J2EE applications to avoid network and invocation protocol overhead.

        Stored procedures allow use of efficient RDBMS constructs. In some cases, this will lead to significantly higher performance and reduce load on the RDBMS.

        Many data management problems can be solved much more easily using a database language such as PL/SQL than by issuing database commands from Java. It's a case of choosing the right tool for the job. I wouldn't consider using Perl in preference to Java to build a large application; neither would I waste my time and my employer's money by writing a text manipulation utility in Java if I could write it in Perl with a fraction of the effort.

        There may be an investment in existing stored procedures that can be leveraged.

        Stored procedures are easy to call from Java code, so using them tends to reduce, rather than increase, the complexity of J2EE applications.

        Very few enterprises with existing IT shops have ported all their applications to J2EE, or are soon likely to. Hence persistence logic may be more useful in the RDBMS than in the J2EE server, if it can be used by other non J2EE applications (for example, custom reporting applications or in-house VB clients).

        The danger in using stored procedures is the temptation to use them to implement business logic. This has many negative consequences, for example:

        There is no single architectural tier that implements the application's business logic. Updates to business rules may involve changing both Java and database code.

        The application's portability will reduce as stored procedures grow in complexity.

        Two separate teams (J2EE and DBA) will share responsibility for business logic, raising the possibility of communication problems.

        If we distinguish between persistence logic and business logic, using stored procedures will not break our architecture. Using a stored procedure is a good choice if it meets the following criteria:

        The task cannot be accomplished simply using SQL (without a stored procedure). There is a higher overhead in invoking a stored procedure using JDBC than in running ordinary SQL, as well as greater complexity in the database.

        The stored procedure can be viewed as a database-specific implementation of a simple Java interface.

        It is concerned with persistence logic and not business logic and does not contain business rules that change frequently.

        It produces a performance benefits.
        The code of the stored procedure is not unduly complex. If a stored procedure is appropriate, part of the payoff will be a simpler implementation than could have been achieved in a Java object running within the J2EE server. Especially in an organization with DBA resources, 10 lines of PL/SQL will prove easier to maintain than 100 lines of Java, as such a size discrepancy would prove that PL/SQL was the right tool for the job.

        ImportantВ
        Do not use stored procedures to implement business logic. This should be done in Java business objects. However, stored procedures are a legitimate choice to implement some of the functionality of a DAO. There is no reason to reject use of stored procedures on design grounds.
        Chapter 7: Data Access in J2EE Applications
        Working with Relational Databases
        Expert One-on-One J2EE Design and Development
        by Rod Johnson
        ISBN:0764543857
        Wrox Press В 2003
        [i]'Drawing on the author's experience'[\i]

        I do support this. It fits my bill in terms of my professional experience perfectly and if '10 lines of PL/SQL will prove easier to maintain than 100 lines of Java' I'll go for PL/SQL.

        There is place for Java and there is place for PL/SQL. Business logic vs. Persistence logic.

        Comment


        • #19
          Hi Arno,

          I think Rod was talking about certain requirements and whether they should be validated in a stored procedure or in Java code. However, even if they are implemented in a stored procedure, the code is aware of the validation and is invoking the stored procedure. I would think that when it is possible to perform the validation in a stored procedure and the result from the stored procedure is enough to provide valuable feedback to the user in the event of an error, then it makes sense as an option. However, we are talking about a simple database constraint, so the question is, "Should we add an additional check on the Java-side for the benefit of the user"? I think using Rod's argument would only be applicable if you are explaining why we should consider writing a stored procedure to determine if the data is valid rather than using Java code. However, you are not suggesting that; you are suggesting that we simply rely on the database constraint.

          I also disagree with your statement that "Those DBA guys changed something in their trigger code, OK my code will react to their change with a properly handled exception." Let's assume that the User entity, stored in the USER database table, currently has a single unique constraint (besides its auto-generated primary key), for the column USER.USERNAME. Then the developer who tries to save a new user and catch the DataIntegrityViolationException might be tempted to alert the user that the username chosen is already taken (given that there is only one field that could have been the offending field). Well let's say that later there is an added business rule that states each user's email address must be unique. If this is implemented only by adding the database unique constraint to the USER.EMAIL_ADDRESS column and the code is left alone, then a user may get an incorrect error message telling him that the username is already taken, when the problem might be that the email address is taken. So I don't think that similar business rules can be implemented in the database without regard for or a change to the code.

          My whole argument is based on the fact that I don't understand how to provide a user-friendly error message when catching a DataIntegrityViolationException exception. If I am wrong, I apologize and void my argument

          -Arthur Loder
          Last edited by Arthur Loder; Aug 25th, 2006, 10:46 AM.

          Comment


          • #20
            Originally posted by Arthur Loder
            I definitely understand what you mean with regards to the problems associated with maintaining the validation rules in the database and Java code. But my question is this: even if you do catch the DataIntegrityViolationException, how would you provide an informative error message to the user?
            Hi Arthur,
            It's an issue of separation of concerns.
            Whoever wrote PL/SQL code should provide semantically clear exception (if they don't - they do not deserve their salary). Not just obscure db-specific code. PL/SQL has a very advanced exception handling and propagation capabilities. PL/SQL generates semantically clear exception. I can catch it up, unwrap it, and display to the user.

            Comment


            • #21
              goody! I love you compare your own statements with this huge bible that you wrote for me to refer which I know by heart. And yes I do know who Rod johnson is and his relation to spring framework. I also know his relation to interface21. Therefore quote his writings and don't scold me with his name. I would suggest you reread the last para of what you wrote. I never said stored procedures are not good all together. Stored procedures are useful and extremely useful when it comes to complex calculations on values stored in database rather than making 15 different database calls from java code to complete the task. Dang Rod! is it your writing that is making hard for people to understand or is it them?

              Lets get back to scenario, so you want to go through pains of doing a database IO just to know if provided data is dirty data?

              Hummmm, I wonder if Rod Johnson ever mentioned in his book that "Round trips are not good for just to know if provided data would violate RI of database.

              Comment


              • #22
                Back to the original question

                Hi Again Arno,

                Maybe this thread is so long that I forget what it about

                We are talking about a very specific scenario: a unique constraint on a username. Are you suggesting that we should write PL/SQL code in this case? If so, then you are agreeing that simply relying on a database unique constraint is not enough, and you are choosing to implement the rule in PL/SQL rather than Java code; this is more a matter of personal preference. If not, and we simply attempt to save the object and catch the DataIntegrityViolationException, then please explain how to notify the user which input data was incorrect so he can fix it.

                Originally posted by Arno Werr
                Hi Arthur,
                It's an issue of separation of concerns.
                Whoever wrote PL/SQL code should provide semantically clear exception (if they don't - they do not deserve their salary). Not just obscure db-specific code. PL/SQL has a very advanced exception handling and propagation capabilities. PL/SQL generates semantically clear exception. I can catch it up, unwrap it, and display to the user.
                -Arthur Loder

                Comment


                • #23
                  @Arthur

                  Originally posted by sk
                  Hi all,

                  Suppose we are implementing the code for "register a new user to Spring forum". And you need to guarantee that username is unique...

                  (There is a service layer, a dao layer, and a view layer. Using declarative transaction management.)

                  Here is what i thought:

                  hmm, i can put a constraint check in database, let Spring throw DataIntegrityViolationException and catch it in the service layer and
                  wrap it within a more specific and meaningful exception and throw the new exception.

                  Here is the service layer code:
                  Code:
                      @Transactional
                      public void save(User User) {
                          try {
                              dao.save(user);
                          } catch (DataIntegrityViolationException ex) {
                              throw new BusinessException("Duplicate username.");
                          }
                      }
                  You might guess what actually happens in this situation; i can't catch the exception, because dao.save(user) would not really save to the database
                  (hence the constraint viloation does not manifest) until transaction commits (when the save method exits).

                  Any suggestion? What do you think i should do?
                  Well, if it is enough for Sammy, it is enough for Arno.

                  Comment


                  • #24
                    Originally posted by Arthur Loder
                    We are talking about a very specific scenario: a unique constraint on a username. Are you suggesting that we should write PL/SQL code in this case? If so, then you are agreeing that simply relying on a database unique constraint is not enough, and you are choosing to implement the rule in PL/SQL rather than Java code; this is more a matter of personal preference. If not, and we simply attempt to save the object and catch the DataIntegrityViolationException, then please explain how to notify the user which input data was incorrect so he can fix it.
                    Arthur,
                    Following your effort to pull it back onto the track , it's probably worth noting that there are actually two issues brought up in OP's scenario. One is how to intelligently convert DataIntegrityViolationException to some kind of business exception that is more specific on exactly what went wrong.

                    The other one is something more or less caused by the use of declarative transaction, compounded by Hibernate's flush mechanism. In other words, since the declarative transaction code is wrapped around the service method, any DAO exception thrown in that code cannot be caught and converted by the service method. Forcing a flush in the DAO code sounds to me like more of a hack than a solution because to some extent it defeats the purpose of hibernate's smart flushing algorithm. Maybe these are the cases where we should revert back to the good old programmatic transaction try/catch block entirely within the service method?

                    Comment


                    • #25
                      Originally posted by manifoldronin
                      Maybe these are the cases where we should revert back to the good old programmatic transaction try/catch block entirely within the service method?
                      No, not the bad old days

                      I personally would consider programmatic transaction management more hacky than an interceptor based solution as originally proposed, but maybe I have been doing this IoC thing for too long

                      Comment


                      • #26
                        Originally posted by manifoldronin
                        Forcing a flush in the DAO code sounds to me like more of a hack than a solution because to some extent it defeats the purpose of hibernate's smart flushing algorithm.
                        Looks like a hack? Maybe. Yet hack recommended by the Hiberntate development team.
                        Originally posted by manifoldronin
                        Maybe these are the cases where we should revert back to the good old programmatic transaction try/catch block entirely within the service method?
                        Care to elaborate? Exactly how?
                        Sammy already is calling from service layer
                        Code:
                        @Transactional
                            public void save(User User) {
                                try {
                                    dao.save(user);
                                } catch (DataIntegrityViolationException ex) {
                                    throw new BusinessException("Duplicate username.");
                                }
                            }
                        and as he puts it
                        i can't catch the exception, because dao.save(user) would not really save to the database (hence the constraint viloation does not manifest) until transaction commits (when the save method exits).

                        Comment


                        • #27
                          New Thread Offshoot

                          Hi All,

                          As Jing pointed out, this branched off into two separate ideas; I started a separate thread to explore the validation and error reporting aspects of persisting an entity in which there may be unique constraint violations.

                          -Arthur Loder

                          Comment


                          • #28
                            OK, I am going to take a final stab at this one. primary and foreign keys are for referencial integrity for database itself so that tables doesn't have ghost entries. Like many IT big guns says and we all learned from our experiences, DO NOT USE DATABASE FOR YOUR BUSINESS LOGIC. a duplicate entry should not occure that is a business decision and defined by Business and must be implemented in application. Let database do its own thing for its own good. Do not monkey with it.

                            Comment


                            • #29
                              Originally posted by yatesco
                              No, not the bad old days

                              I personally would consider programmatic transaction management more hacky than an interceptor based solution as originally proposed, but maybe I have been doing this IoC thing for too long
                              I agree with you - in general, and let's not get into the whole subjective "it's not hacky according to me" thing. I'll elaborate in the reply to Arno's post why I thought programmatic transaction might be better in the case in question.

                              Comment


                              • #30
                                Originally posted by Arno Werr
                                Looks like a hack? Maybe. Yet hack recommended by the Hiberntate development team.
                                I have lots of respect and appreciation (at least at professional level) for the hibernate development team for their technical merit and hard work done. However that doesn't mean I do not question, or at least think it through, any recommendation of theirs before "hopping on" . In this particular case, note we are not talking about doing it in just some special cases. If this is the pattern we are to follow to deal with deferred DB exceptions, then any DAO method that can potentially trigger a DB exception at flush-time must explicitly execute a flush() within its body. Maybe "hack" isn't the proper term to describe this situation, but I just still think that it defeats the purpose of hibernate's flushing scheme.

                                Originally posted by Arno Werr
                                Care to elaborate? Exactly how?
                                Sammy already is calling from service layer
                                The reason DataIntegrityViolationException isn't caught in his service method is the commit (hence the flush) doesn't really happen within the service method. In other words, from a caller's perspective, whether the transaction management code is located inside or outside the actual service method should have been irrelevant according to the fundamentals of AOP. And that's why declarative transaction management works perfectly usually - because the caller doesn't feel any difference. Well, that stops being so, when the transaction management code can actually throw some exception that the caller actually would like to catch, now the location of transaction management matters. And that's where we have three choices:

                                1. Stop assuming nothing significant is going to happen between DAO.save()'s exit point and the next statement from where DAO.save() is called, and move the try/catch block to the caller code. That means two things: first, repetitive code as it needs to be done everywhere the service method is called. Second, and more importantly, leak of concern, as in "what the heck is your web controller doing catching dao.DataIntegrityViolationException and converting it to a business exception?!".

                                2. Move the transaction code to inside the service method. Note that that doesn't necessarily mean you have to do all the plumbing - there is still the nice TransactionTemplate. So, yeah, admittedly it involves more typing and a little bit repetitive code inside every service method, but that's obviously better than the first choice.

                                3. Define a pointcut for the exception throwing flow and advice an exception converter. But AFAIK Spring doesn't support that out of box, so it'd have to be done with raw aspectj aspects.

                                Comment

                                Working...
                                X