Re: [Springframework-developer] SpringMVC BeanFactory/Component Scopes

[Brian M. <br...@ap...>]

No, but hibernate sessions are a good example:

Imagine three factories containing components, each with the parent 
(one above) as parent container). Format is as follows (ScopeName 
(ComponentName(ComponentDependencyList) OtherComponent))

(Application (HibernateSessionFactory(DataSource) DataSource Catalog))

(Session (ShoppingCart))

(Request (LazyHibernateSession(HibernateSessionFactory)
		AddToCartThrowAwayController(LazyHibernateSession, Catalog)))

If 500 AddToCartThrowAwayController's are instantiated at any one time 
there will be in the application 1 Catalog, 1 HibernateSessionFactory, 
500 + n ShoppingCart instances (where n is number still in sessions), 
500 LazyHibernateSession instances, and 500 
AddToCartThrowAwayController instances.

Hibernate Session is actually not a great example for this because of 
the "session" namespace collision. Ah well =)

Each HttpSession contains a ShoppingCart (or rather, contains a context 
which contains a shopping cart), each HttpServletRequest (on the 
AddToCartThrowAwayController controller) contains a context which 
contains a LazyHibernateSession and an AddToCartThrowAwayController.

The parent context/factory for each of the request context/factories 
(someone throw me a bone with Spring idiosyncratic terminology here ;-) 
has its respective session set as parent, and all session ones (heh) 
have the application (servlet context, really) one.

Make sense?

-Brian

On Sep 20, 2004, at 4:42 PM, bryan wrote:

> I may have you completely wrong but here is a question.
>
> So people using hibernate session factories etc would have
> one session factory built for every user logged into the web
> container ?
>
> There are a lot of things like this that have a high startup
> cost.
>
> --b
>
>
>
> On Mon, 20 Sep 2004 16:26:57 -0400, Brian McCallister 
> <br...@ap...> wrote:
>> On Sep 20, 2004, at 4:01 PM, Rob Butler wrote:
>>
>>> Hey Brian,
>>>
>>> I don't know about using separate bean factories for
>>> handling session state because usually bean factories
>>> are for creating new (prototype) objects or dishing up
>>> singletons, not storing objects that have been
>>> manipulated in the application.
>>
>> Really, what I want are the one-per-scope "singleton" instances. The
>> session-scoped "singleton" is a PERFECT place for sticking session
>> state, particularly when child factories can build their prototypes
>> from it.
>>
>>> I don't think bean factories will do what your looking to do.
>>
>> Quite possibly not, I have spent a lot more time in the pico world, 
>> but
>> Rod has been doing a good job of trying to get me to convert ;-)
>>
>>> If your really set on trying this approach though you
>>> can construct a new bean factory and then store it in
>>> session.  You can set it's parent to be the
>>> application bean factory, and set where to read it's
>>> config file from.
>>
>> That is exactly what I want. Ideally the beans could sit in the 
>> session
>> directly and be proxied in the container, but as long as the
>> container/factory/context is session compatible (serializable and able
>> to rebuild dependencies intelligently after serialization (proxy proxy
>> proxy!) this works great.
>>
>>> Now what's really neat about this is, I have been
>>> trying to think of a good way to implement dynamic
>>> configuration for a web application... and this looks
>>> like it could fit perfectly.  When your user begins a
>>> new work flow you can "load" the configuration by
>>> requesting a new session scoped bean factory... Which
>>> would actually load the configuration file at that
>>> time and retain all the setings until it was
>>> explicitly refreshed or better yet, removed from
>>> session and a new one loaded when the next workflow
>>> started.
>>
>> =)
>>
>>>
>>> Now all that is needed is to have the various spring
>>> MVC stuff look for a session bean factory BEFORE they
>>> look at the application bean factory.  This would
>>> allow per user configuration state to be maintained..
>>> which is exactly what you need for a dynamically
>>> configurable application... Because you may need to
>>> maintain whatever the configuration was when the user
>>> started the current workflow.. but if their session
>>> times out, or if they finish the workflow subsequent
>>> operations should use the new configuration with the
>>> updates.
>>
>> Exactly!
>>
>>
>>
>> -Brian
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
>> Project Admins to receive an Apple iPod Mini FREE for your judgement 
>> on
>> who ports your project to Linux PPC the best. Sponsored by IBM.
>> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>