Using a Class Property in JSP

I am trying to use a Class Property in my JSP without assigning the property to a session attribute.

I have set up a global class that gets loaded when the application is started on the web server.
The properties are available to all sessions of the application started by users.

Most of these properties(qmsConfigurationParms) are other classes with properties.

Up until now I just assign the properties to session attributes to use in my JSP.
I am getting some issues with having too much session bloat.

How can I use something like this to avoid adding session attributes?

[code]

<div class="miscdisplaysections">
<jsp:useBean id="qmsConfigurationParms" class="com.FAIWebApp._application._startup.globalProperties.QMSGlobalProperties" scope="request"/>

<input type="text" id="biweeklyDocIteration" name="biweeklyDocIteration" size="25" value="${qmsConfigurationParms.byWeeklyStatementArg1}"> Document Iteration

</div>

[code]

Would I need to make the byWeeklyStatementArg1 a direct property of QMSGlobalProperties?

Don't.

a class property in a JSP or servlet (which is what a JSP gets compiled into) has the same basic characteristics as JEE Application Scope. Its not thread-safe and neither class nor instance properties are recommended storage receptacles for JEE application properties.

If you have data that's immutable and common to all apps (such as lists used to generate dropdown menus), store it as an Application Scope object. If you have data that's shared between multiple apps that's not immutable, store it in Application Scope with synchronization.

Tim Holloway wrote:Don't.

This is not multiple apps but one with many modules.
I have many DataRepository classes, each module data specific.
Each class has its own(using connection pooling from server):

Then I have many methods that add/edit/delete remote data.
Several of the modules may need access to the same DataRepository. This is multiplied by a couple hundred user sessions.
I need the DataRepository instance loaded one time when the application starts of the server and active until the server is stopped.

is it correct to place the new DataRepository constructor call in:

Good point, but there's more.

I use Spring Data to manage my persistence infrastructure. And actually, it does directly connect the JPA Entity manager factory to each and every one of my DAOs without going through JEE object storage.

In that particular case, it's certainly reasonable to manage things that way.

As I read it, you're considering something along the same lines.

Although one advantage to using Spring is that it's automatically wiring in the persistence infrastructure using annotations whereas otherwise one has to manually manage it on code. Spring also instantiates the connection management/EntityManagerFactory stuff on the first reference, so I don't have to code that either. It's all there amd ready when I need it.

In a non-Spring environment, I'd typically have a connection manager class that would instantiate itself by doing a lookup of the container's Connection Pool and caching it so that futre getConnection() calls could pull directly from the pool without doing the JNDI, which is perfectly safe.

Of course I'm obligated to point out to those who might not be aware that it is exceedingly dangerous to obtain and hold a Connection, especially between HTTP requests. One should always close the connection (thus returning it to the pool) as soon as it's no longer needed for the current database operation(s).

Tim Holloway wrote:
Of course I'm obligated to point out to those who might not be aware that it is exceedingly dangerous to obtain and hold a Connection, especially between HTTP requests. One should always close the connection (thus returning it to the pool) as soon as it's no longer needed for the current database operation(s).

My code nomenclature may be a little misleading.

My DataConnection actually returns a DataSource:


Then my data look ups use:

Yeah, that's pretty standard, actually.

Although you don't need the terminal ";" on your try-with-resources.

Steve Dyke wrote:


is it correct to place the new DataRepository constructor call in:

Where does this get stored?
Does this play a role in the Heap Size?

The thing that has generated conversation is I found out that 5G of my 10G Max heap size was HttpSession store.

Steve Dyke wrote:

Steve Dyke wrote:


is it correct to place the new DataRepository constructor call in:

Where does this get stored?
Does this play a role in the Heap Size?

The thing that has generated conversation is I found out that 5G of my 10G Max heap size was HttpSession store.

Virtually all objects are stored on the Heap, allowing for a few tweaks like maybe intern'ed Strings, and the late-but-not-lamented storage space that used to make hot-replacements of Tomcat webapps likely to fail. I forget its name.

So yes, if you define a class-scope object in a ServletContextListener, then the object will be a heap object. So will objects in JEE Application, Session, Request and Page scopes. As well as the request and response objects passed to the servlets/JSPs, the Thread objects that run the code, and so forth and so on.

If your Session storage usage is that massive, first I'd determine how many HttpSessions you've got going, second, how much memory each session takes. Third, whether sessions are being made to live longer than they actually need to.

Shrink the amount of data stored in a HttpSession if you can (in particular anything that can be pulled from a database cache). If there are lots of sessions, consider using ReST or clustering. And never store an HttpSession object in another object or you may end up with orphan sessions. Always get it from the current HtpServltRequest object (getSession()).

Note also that HttpSession-stored objects must always be Serializable. This gives the webapp server the flexibility to "page out/in" HttpSessions to external store and thus minimize the amount of active RAM required (plus a cluster can load-balance by tossing HttpSessions between servers).

Tim Holloway wrote:

If your Session storage usage is that massive, first I'd determine how many HttpSessions you've got going, second, how much memory each session takes. Third, whether sessions are being made to live longer than they actually need to.

If there are lots of sessions, consider using ReST or clustering.

Note also that HttpSession-stored objects must always be Serializable.

Could you elaborate on the how to for these suggestions?

I use this to instantiate each session(this is the only place return getSession(true); is used). This code is in the filter implementation:



I have the timeout set to 30 minutes. Here I run a session.invalidate(); and also when the application(session is manually closed.

The total size of the session is the (unknown) size of HTTPSession plus the sum of the sizes of all objects stored in Session scope, no matter when they are added.

Incidentally, destroying a session based on a timer is a questionable proposition. The server itself will destroy the HttpSession if a request comes in after the webapp's httpsession timeout has expired. It may also destroy the session as a form of garbage collection at an indeterminate time if the session timeout has been reached. You can also prematurely "timeout" a session by forcibly destroying it, of course, which is how historically webapps have implemented a manual user logout.

If you are using JEE standard container-based security, the act of detroying the HttpSession logs you off by virtue of the simple fact that the UserPrincipal object, which anchors a secured user (login) is stored in an HttpSession. So if you're using JEE container security, every logged in user counts as an instance of HttpSession.

I don't recall offhand what tools are available to keep a tally of HttpSessions and besides, the last few employers I had were too cheap to buy any third-party monitoring tools, but at a minimum you could tally them manually in the HttpSessionListener.

ReST, by definition, doesn't employ HttpSessions. That's what makes it ReST.

As for clustering and/or external HttpSession store, that's a complex subject.