AW: Barracuda -- caching

Hi Christian,

Well, thank you for your detailed answer.
 
For that what I can understand, correct me if I am wrong:
Barracuda provides 
- an object pooling mechanism to lower memory consumption,
- a memory management capability that can determine which object should be
freed from the memory, depending on its categorization (soft or weak),
- a caching mechanism for both Servlet and non-Servlet environment, 
- a granular caching mechanism with four levels (Global, Session, Local,
Object).

Barracuda has a general-purpose, highly configurable and flexible caching
mechanism.

My question:
- can this mechanism be easily turn on/off without getting into the code?

Cheers,

Guillaume

-----Ursprüngliche Nachricht-----
Von: Christian Cryder [mailto:[email protected]] 
Gesendet: Montag, 27. Oktober 2003 17:01
An: [email protected]
Betreff: RE: [Barracuda] Barracuda -- caching


Hi Guillaume,

Yes, Barracuda does provide a caching mechanism - I'll repost a summary from
a couple of days ago, and then if you have further questions you can respond
and we'll talk! :-)

Christian
----------------------------
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"


----------------------------------------------
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 Canavaggio 
> Guillaume ZFF PA-K
> Sent: Monday, October 27, 2003 10:45 AM
> To: '[email protected]'
> Subject: [Barracuda] Barracuda -- caching
>
>
> Hello,
>
> I was wondering whether Barracuda provides a caching mechanism or not.
>
> If the answer is positive:
> - is Barracuda's cache a special-purpose or a general-purpose cache?
> - does Barracuda provide facilities to monitor the size of the cache?
>
> Mit freundlichen Gruessen
>
> Guillaume Canavaggio
>
> Informatik Vorentwicklung (IV) / Advance IT Development
> ZF Friedrichshafen AG, D-88038 Friedrichshafen, Germany
> Tel.: +49 / 0/ 7541 77- 3950
>
> _______________________________________________
> Barracuda mailing list
> [email protected] 
> http://barracudamvc.org/lists/listinfo/barracuda

_______________________________________________
Barracuda mailing list
[email protected] http://barracudamvc.org/lists/listinfo/barracuda