Announcement Announcement Module
Collapse
No announcement yet.
Why OpenSessionInViewFilter is misleading and useless in most cases Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by pmularien View Post
    This can be mitigated with adjustments to hibernate settings, IIRC.
    Yes, you can set the batch size on a collection mapping. So it gets an 1 + N/batch size issue. That's why I didn't formulate it too absolute in my first answer.

    Jörg

    Comment


    • #17
      Originally posted by jglynn View Post
      Regarding OSIV; my beef is mostly with regards to the inability to re-attach an object to the new session. As a result, binding must occur against a new object (retrieved from the database) because you cannot bind against the object you got in the previous request. Reason being, you'll be unable to persist that object as it's still tied to the previous session which has since been closed. Not only is this useless overhead, but it creates all sorts of problems when you'd like to take advantage of things like hibernate versioning for example.
      As far as I understand this is not a problem with OSIV but with Hibernate in general - as long as you don't have anything like extended sessions. I still don't have the silver bullet.

      Jörg

      Comment


      • #18
        Very true, I suppose I mistakenly identify it with OSIV because that's the pattern I'm using but you're right, this is a Hibernate issue.

        A comment you made in another thread
        That's why a detached object should just lazily reattach when necessary and a session is available. Like I provide a transaction declaratively and transparently I would do it with a session
        is precisely the functionality I desire.

        Comment


        • #19
          Am I the only one thinking that the OSIV pattern is more an anti-pattern than a pattern ?

          It seems to me that it breaks a basic design principle. A layer should not rely on layers above it and should only know of services in its own layer or sublayers.

          In OSIV, the business or eis layer (data layer) is dependant on the web layer. Isn't that completely wrong ?

          What I see in OSIV is a big patch for projects that have developed with lazy attribute to false for every collection thinking that they would improve performance at the end of the project. Then you would need OSIV, otherwise you would have a bunch of LazyLoadingException. But this is a patch...

          Another point, you are putting hibernate stuff in the presentation layer. This layer should not even be aware that you are using hibernate.

          Your services are not reusable through web services (might not be a big issue) since there is no session available.

          Also, by using the OSIV, you will most probably generate N+1 selects as mentioned. You should be opmimizing your fetching either through join="fetch" or join="subselect" among possibilities.

          There would be many reasons why not to use OSIV, but as previously mentioned, simply because your business layer relies on your presentation layer is a good enough reason for me to avoid it. At that point, let's have all classes in the presentation layer...

          Your opinion would be more than welcome.
          Regards,
          Alain Bergeron

          Comment


          • #20
            Originally posted by berkum View Post
            In OSIV, the business or eis layer (data layer) is dependant on the web layer.
            With the rather standard architecture with data access, service and web layer you suffer from the same "problem". The data access is "dependent" on the service layer. But in both cases it's not really a dependency, transactions are a cross-cutting concern.

            Originally posted by berkum View Post
            What I see in OSIV is a big patch for projects that have developed with lazy attribute to false for every collection thinking that they would improve performance at the end of the project. Then you would need OSIV, otherwise you would have a bunch of LazyLoadingException. But this is a patch...
            I can agree with this view.

            Originally posted by berkum View Post
            Another point, you are putting hibernate stuff in the presentation layer. This layer should not even be aware that you are using hibernate.
            OSIV has nothing to do with the presentation - or in other words, the presentation layer is still not aware at all that Hibernate is involved. It's still a cross-cutting concern and applied via a filter or an interceptor. If you do this on the web or the service layer doesn't make a difference IMO.

            Originally posted by berkum View Post
            Also, by using the OSIV, you will most probably generate N+1 selects as mentioned. You should be opmimizing your fetching either through join="fetch" or join="subselect" among possibilities.
            The patch character with the potential and likely negative side-effects outlined by you are the actual issues with OSIV. I would not care about on which layer it is actually applied otherwise.

            Joerg

            Comment


            • #21
              Originally posted by Jörg Heinicke View Post
              OSIV has nothing to do with the presentation - or in other words, the presentation layer is still not aware at all that Hibernate is involved. It's still a cross-cutting concern and applied via a filter or an interceptor. If you do this on the web or the service layer doesn't make a difference IMO.

              Even though the implementation is through ServletFilter, this is part of the servlet api. This for me is the presentation layer. Of course, application code need not be aware of this mecanism, still I don't like the idea of providing access to hibernate api in the web layer. This means other programmer can start calling hibernate api in their servlet, actions or else. And they will. This will lead very bad code.

              Still, I got your point right. Thank you.

              Comment

              Working...
              X