RE: webapp design question

Hi Thelmo,

Ok, so as Jake has already noted, the ObjectRepository provides an alternate
interface for putting data in the Session, but you may want to be careful
how much stuff you put in there as that will definitely increase the
footprint and reduce scalability of the app. A general principle is that you
want to put as little as possible in the session - and if you do have some
objects that you want to store there for convenience/performance purposes,
you may want to store them as "soft" or "weak" objects, allowing them to be
gc'd if the JVM starts to run low on memory. Barracuda's ObjectRepository
can help here too with its cache repository.

Here's an overview of what the ObjectRepository class gives you -

There are 3 "global" repositories -

    public static ObjectRepository getGlobalRepository() {
    public static ObjectRepository getWeakGlobalRepository() {
    public static ObjectRepository getSoftGlobalRepository() {

These are shared across the JVM, so they are useful if you want to share
things globally. Weak and soft repositories allow objects to be gc'd by the
JVM as needed, so they are a great "cache" mechanism (see the jdk javadocs
for the difference between weak vs. soft)

Likewise, there are 3 "session" repositories that are basically the same as
the global repositories, except they are scoped to session -

    public static ObjectRepository getSessionRepository() {
    public static ObjectRepository getWeakSessionRepository() {
    public static ObjectRepository getSoftSessionRepository() {

Next you have a "local" respository -

    public static ObjectRepository getLocalRepository() {

The local that is scoped within the http request/response cycle - anything
you put in here (ie. in a request handler) will be available to all other
portions of your code (ie. in a response handler, internal data layer
objects, etc). In other words, any code executed within the same thread are
going to have access to objects in this repository. And any objects placed
in this repository are automatically removed at the end of the req/resp
cycle - so you don't have to worry about cleaning things up (unlike global,
session, or other repositories).

Finally, there is a method that allows you to get "regular" repositories
using a Namespace or String naming convention - allowing you to set up your
own object repository strategies:

    public static ObjectRepository getObjectRepository(NameSpace ns) {
    public static ObjectRepository getObjectRepository(String name) {

Ok, so now on to the next question: why use the ObjectRepository structure
at all? Why not just stick stuff directly into the session? Well, first of
all, the ObjectRepository provides a common interface to access the same
structure in a number of different scopes - without changing your code that
puts data in/gets data out of the repository.

Second, the ObjectRepository approach provides a layer of abstraction -
let's say you are writing code that stores stuff in the session; this works
in the HTTP Servlet environment, but what if all of a sudden your code needs
to also run in non-servlet environment (like test cases). If you are
hardcoded to the servlet interface, you are stuck; but if you are using the
Obj. Repos (OR) approach, then everything continues to work (if there is no
Servlet session object available, it just creates a backing map structure) -
the point here is that your code can now work in both servlet -and-
non-servlet environments. That's pretty useful.

Finally, the ObjectRepository approach also gives you the ability to script
objects into the global repository from an xml file. For instance, you can
use the ObjectRepositoryAssembler to set up datasources:

    <object name="$ds" class="com.jnetdirect.jsql.JSQLPoolingDataSource">
        <method
name="setURL">jdbc:JSQLConnect://localhost/database=ATMReportsDev/user=sa</m
ethod>
        <method name="setMinPoolSize">2</method>
        <method name="setMaxPoolSize">10</method>
        <method name="setMaxIdleTime">60</method>
        <method name="setPropertyCycle">2</method>
    </object>
    <register key="DB_ATMR" val="$ds"/>

to configure static variables:

    <object class="com.atmr.atmreports.AppKeys">
        <prop name="WEBINF_PATH">E:\WebApps\foo\Blah\WEB-INF</prop>
        <prop name="EMAIL_USERS">false</prop>
    </object>

etc.

The bottom line is that the whole ObjectRepository way of doing things has
some very key advantages - we use it quite extensively, and I can't imagine
building webapps without it.

Does that help explain things a bit?

Christian
----------------------------------------------
Christian Cryder
Internet Architect, ATMReports.com
Project Chair, BarracudaMVC - http://barracudamvc.org
----------------------------------------------
"Coffee? I could quit anytime, just not today"


> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Jacob Kjome
> Sent: Thursday, October 23, 2003 11:59 AM
> To: [email protected]
> Subject: Re: [Barracuda] webapp design question
>
>
> Hi Thelmo,
>
> At 10:23 AM 10/23/2003 +0200, you wrote:
> >In my webapp i've to keep a lot of per-session information, with a lot i
> >mean quite large ArrayList, at least one object which has socket writing
> >and reading capabilities and of course some basic data and user states.
> >
> >Is the object repository within barracuda (mapped with http session
> >scope) the best place where to store this infos !?
>
> I believe that is what it was created for.  It automates the handling of
> issues such as thread safety and object cleanup and doesn't require that
> you have access to an HttpRequest object in order to get access to the
> HttpSession object.  Sounds to me to be an ideal place to store your
> objects.  I would, however, watch how much stuff you put into the session
> repository.  Depending on how many users you have, you could end
> up running
> out of memory with too many sessions with too much stuff in them.  Note
> that the ObjectRepository allows you access to the global and
> local scopes
> which allows you store some stuff which might not be required to
> store per
> user session allowing you to save on system resources.
>
> I'll let Christian add more specifics if need be.
>
> Jake
>
> _______________________________________________
> Barracuda mailing list
> [email protected]
> http://barracudamvc.org/lists/listinfo/barracuda