tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Assaf Arkin <>
Subject Re: [TOMCAT.NEXT] Proposal Sources Checked In
Date Sat, 08 Jan 2000 18:13:17 GMT
> * A "Store" inteface that abstracts mechanisms
>   for persistent storage of sessions (for use across
>   server restarts and/or when auto-reloading is
>   implemented).
> * Implementations of this interface for flatfiles and
>   JDBC databases (plus any others that people
>   want to use).


As always, a question about how this plays with the other stuff (I'll be
waiting for the API to see how the components interact).

- Do you automatically store/reload all the sessions?

- When doing auto-reloading, will it break if one of the classes has
been changed?

- Is there any specific transaction context during that store?

- Do you load/store them all at one, or is it possible to do this one at
a time, or should I just plug in a different Interceptor to do that?

> The original thinking was that the configuration process for a container
> would be going through the appropriate parameters, and call addInterceptor()
> to add each defined Interceptor.  Within the addInterceptor() implementation,
> the container would call the Interceptor's setContainer() method, as outlined
> in the Javadoc comments for addInterceptor().  This chain of events could be
> interrupted by any of the following cases:

Assuming that only the configuration code is allowed to call
addInterceptor, which as I recall is a public method.

Anyway, I don't like InvalidArgumentException as "I reject doing
something". Look at the event listener interface for example. When you
add two listeners to a source that can only support one, it throws a
TooManyListeners exception, not an IAE.

> * Container does not support any Interceptors, or
>   any more Interceptors (so addInterceptor() throws
>   IllegalStateException).
> * Container refuses to accept this particular Interceptor
>   (so addInterceptor() throws IllegalArgumentException)
>   -- this one is not documented yet, but will be.
> * Interceptor is already attached to a different Container
>   (so setContainer() throws IllegalStateException)
>   -- this one is not documented yet, but will be.
> * Interceptor refuses to be attached to this particular
>   Container (so setContainer() throws IllegalArgumentException).

I totally agree with these four cases, I just don't like the use of IAE,
but ISE is used exactly as it was ment to be.

> Are you thinking of any particular case?  I believe that the only
> implementations included in the proposal already build an array on the stack
> before they return it (like ContainerBase.findChildren() does).  Therefore,
> the internal collection itself is not corruptible.  The objects returned in
> the array are the "real" objects from the collection, because that is what
> the caller wants to deal with.

Good. Keep it that way.

This sort of problem doesn't happen when you're returning an array from
a collection, it only happens if you're returning an array from an
array. (Yep, it just bit me :-) )

> By the way, I chose to return arrays for these kinds of things for the
> following reasons:
> * The number of objects in any of these collections will tend to be
>   pretty small, so we're not occupying huge amounts of space for
>   the array itself.
> * Avoids the decision between returning an Enumeration (JDK 1.1)
>   or an Iterator (JDK 1.2).  If and when Tomcat migrates to requiring
>   JDK 1.2 or later, these interfaces will not change.
> * Returning the complete array avoids race conditions that can happen
>   with Enumerations or Iterators when another thread is modifying the
>   underlying collection while you are walking through the results.

All sound reasons.


> >
> > arkin
> >
> Craig
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message