excalibur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject [RT] About proxies and pooling
Date Thu, 24 Jun 2004 07:00:48 GMT
Ok, let's start thinking about some "new" things :)
(Actually this is not new but who cares?)

a) Proxy Handling in Fortress
Currently it's possible to define/configure if/how Fortress
is creating a proxy for a component. I'm wondering if this
flexibility is really required.
I think we should always create a proxy.

There are imho three reasons:
- security: if you create a proxy, the client can't cast
  the component to the implementation class. 

- Performance/remove a bottle neck: currently without a proxy
  all components are stored on lookup in a big hash map together
  with their handler and on release the handler is taken out the
  map to properly release the component. So this map is a bottle neck 
  for multi-threaded apps.
  With a proxy we can store the handler in the proxy and remove
  this bottle neck. Actually this is already implemented in Fortress
  if you use proxies :)

- Better Support for non thread-safe components. See below.

Now, by always creating a proxy we can remove/clean up some code
in Fortress and it gets a little bit smaller as well :)

WDYT?

b) Pooling (or handling of non thread-safe components)

A problem that always bites me is that you have to know if a component
is thread safe or not. For example, if you have a thread safe component
that uses other components, then you can't simply lookup this component
in service()/compose(). You can only safely do this, if the component
implementation you look up is thread safe as well.
If it is pooled or single threaded you have to lookup/release this component
each time you use it. 
So, if you really want to develop a multi-threaded app, you either have
to know which components are thread safe or not  or  you have to lookup
release a component each time you use it. I think both solutions are not
very nice :)

Now, there have been a lot of discussions about this topic. For example,
we had suggestions that all components should be thread safe. Even if 
this would be an option for the future, it's just this: "the future". We
currently have a lot of apps out there that use pooled and single threaded
components.
Similar is the discussion about pooling components yourself or let the JVM
pool them for you. This way or that way: the components are pooled but not
thread safe.

So, a rather long introduction for the problem :) Now, I think one solution
for this
is to say "let's pretend that all components are thread safe". So, the basic
idea is to create a proxy for each component that ensures that the use
of the underlying component is in a thread safe way (and this is the third
reason for proxies).
For example, if you're using a pooled component, you get a proxy that during
one request, fetches a component from a pool - if the component is used -
and releases the component when the request is finished.
Therefore you need to notify the container when a request starts and
finishs.

During the request the pooled components are stored somewhere (thread local 
for example) and when the request is finished they are released.

This mechanism is only required for pooled or single threaded components,
thread safe components don't need this extra behaviour.

This would allow the client to lookup a component in service() and just
use it and the underlying logic takes care that you don't get threading
problems.

I conclude from the docs, that e.g. HiveMind is doing it this way.

WDYT?

Carsten 

Carsten Ziegeler 
Open Source Group, S&N AG
http://www.osoco.net/weblogs/rael/


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/


Mime
View raw message