The constant web design wall I keep hitting [long]

[Michael Rimov]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Well guys, since you're the savviest developers I've known, I'm going to ask you this question.

 

Consider the following typical tiered stack:

 

public class SomeDao {

      public SomeDao(org.hibernate.Session session) {

            /** Stuff here **/

      }

}

 

public class SomeService {

      public SomeService(SomeDao dao) {

            /** More stuff :) */

      }

}

 

public class SomeController {

      public SomeController(SomeService service) {

            /** Seeing the pattern?  :) **/

      }

}

 

Now Consider the following assembly in NanoWAR:

 

MutablePicoContainer mpc = new PicoBuilder()

.withBehaviors(new NanoWarStuff())

.withLifecycle().build();

 

mpc.as(REQUEST_SCOPE).addComponent(o.p.persistence.hibernate.ScopedSession.class)

      .addComponent(SomeController.class)

      .addComponent(SomeService.class)

      .addComponent(SomeController.class);

 

So here’s my problem:

 

Since Hibernate Session is a request scope, that means:

·         SomeDao depends on Hibernate Session, it must reside in Request Scope

·         SomeService depends on SomeDao which depends on Hibernate: it must reside in Request Scope

·         And finally, SomeController depends on SomeService which depends on SomeDao which depends on Hibernate:  therefore it must reside in the Request Scope.

 

The end result is that because one dependency is request-level scope.  EVERYTHING get dragged down with it, which equals poor performance.  (Reusable Pico can help here, but only so much).  The only non-threadlocal workaround I’ve come up with is instead of using ScopedSession, have:

 

public class SomeDao {

 

      private final SessionFactory sessionFactory

      public SomeDao(org.hibernate.SessionFactory sessionFactory) {

            this.sessionFactory = sessionFactory;

      }

 

      public void doSomething() {

            Session hibernateSession = sessionFactory.createSession();

            try {

                  /** do action **/

            } finally {

                  hibernateSession.close();

            }

           

      }

}

Between my options, in many ways, this is worse performance than before!

 

If I include thread local storage for each request object, I can get it down to:

 

public class SomeDao {

 

      /** Request container would put a ThreadLocal session reference in ‘sessionReferenc’ **/

      private final HibernateSessionReference sessionReference;

 

      public SomeDao(HibernateSessionReference sessionReference) {

            this.sessionRerence = sessionReference;

      }

 

      public void doSomething() {

            Session hibernateSession = sessionReference.get();

           

            /** Close is handled by the sessionReference factory **/

      }

}

 

But I tend to agree that Threadlocal is the new static and  I try to avoid it whenever possible.  But at least the threadlocal here is limited to one class instead of propagating up the stack.

 

So.  Any thoughts on other solutions to stop/minimize request-level propagation?

 

                                          -Mike

[Mauro Talevi]

Michael Rimov wrote:

> So here’s my problem:
>
>  
>
> Since Hibernate Session is a request scope, that means:
>
> ·         SomeDao depends on Hibernate Session, it must reside in
> Request Scope
>
> ·         SomeService depends on SomeDao which depends on Hibernate: it
> must reside in Request Scope
>
> ·         And finally, SomeController depends on SomeService which
> depends on SomeDao which depends on Hibernate:  therefore it must reside
> in the Request Scope.
>

IMO this is the key aristotelic syllogism:  it depends on hibernate
therefore it must reside in (webapp) request scope.

Why do you assume this?  You can happily have a persister/dao living in
application scope and it will fire off different hibernate requests.

I tend to have most dependencies living in app scope and only use
session or request when strictly necessary.

Am I missing something?

Cheers


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Paul Hammant-3]

I'm with Mauro Mike.

hibernate and DAO stuff should definitely be in app scope (standard  
picocontainer + caching)

Take a look at http://svn.codehaus.org/picocontainer/java/2.x/trunk/web/examples/struts2-webapp/ 
  and the WebappComposer class for it - http://svn.codehaus.org/picocontainer/java/2.x/trunk/web/examples/web-example/src/java/org/picocontainer/web/sample/ExampleWebappComposer.java

The DAO is at app level. There is a DefaultCheeseService is at session  
level for the example, but could as easily be in app scope.  Requests  
scope things like "AddCheese" "RemoveCheese" are added laziily later.

Remember Pico now no-longer stores whole containers in Servlet Context/
Session.  It only stores the session container's instantiated session  
components (as a set) in the session scope.  ThreadLocal can be over  
used, but its appropriate for PicoContainer to use it behind the  
scenes for a session/request scoped thing.  Components themselves  
should not have to know about or participate in ThreadLocal usage.  
I.e. we're still honoring our transparency goal.  I'm really pleased  
with the efficiency and speed improvements for the new stype of Pico  
webapps over the old.

Regards,

- Paul

On Jun 27, 2008, at 12:52 AM, Mauro Talevi wrote:

> Michael Rimov wrote:
>
>> So here’s my problem:
>> Since Hibernate Session is a request scope, that means:
>> ·         SomeDao depends on Hibernate Session, it must reside in  
>> Request Scope
>> ·         SomeService depends on SomeDao which depends on  
>> Hibernate: it must reside in Request Scope
>> ·         And finally, SomeController depends on SomeService which  
>> depends on SomeDao which depends on Hibernate:  therefore it must  
>> reside in the Request Scope.
>
> IMO this is the key aristotelic syllogism:  it depends on hibernate  
> therefore it must reside in (webapp) request scope.
>
> Why do you assume this?  You can happily have a persister/dao living  
> in application scope and it will fire off different hibernate  
> requests.
>
> I tend to have most dependencies living in app scope and only use  
> session or request when strictly necessary.
>
> Am I missing something?
>
> Cheers
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Konstantin Priblouda]

----[ Konstantin Pribluda http://www.pribluda.de ]----------------
JTec quality components: http://www.pribluda.de/projects/


--- On Fri, 6/27/08, Mauro Talevi <mauro.talevi@...> wrote:

> IMO this is the key aristotelic syllogism:  it depends on
> hibernate
> therefore it must reside in (webapp) request scope.

Indeed, there is a problem arising from idea  that no container component
shall even know a scope below does exist.

> Why do you assume this?  You can happily have a
> persister/dao living in
> application scope and it will fire off different hibernate
> requests.

Well, the problem is, where does dao gets his session?
Need to manage it in dao invalidates whole idea of DI

OK, I can think about some component that
 - pretends to be a session
 - lives in app scope
 - transparently delegates to (hot swappable)
real session managed in request scope

Another tricky issue are hibernate entities. They are definitely of
litte use outside  their own session (ok, they can be detached, but
then you slurp in whole object tree, and hibernate folks produce
subtle changes in behaviour even on minor releases)

regards,


     

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email