Mailing-List: contact user-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cayenne.apache.org
Received-SPF: pass (athena.apache.org: domain of mkienenb@gmail.com designates
 74.125.46.156 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=VFC1AXuvn7sj788TWpOz8YhhZAKbir4UMImWBVCMNFGIYi6XbZ1Po8v2T22jUGZRaRvXPTN6Jwh+zZ4S+jjy20WrbaTuJmz/46QtJ+3Lk+aLKkkkd4dulwV+/OQOScYr7uSzX6lxFFnfOtXWsb8/UzOzoYShNMWiEIUcFenXxpw=
Message-ID: <8f985b960805051006l1cafc931h2e4621fbac4c68cb@mail.gmail.com>
Date: Mon, 5 May 2008 13:06:36 -0400
From: "Mike Kienenberger" <mkienenb@gmail.com>
To: user@cayenne.apache.org
Subject: Re: Invalidating cache from external process?
In-Reply-To: <D9785385-3D2B-41A9-9082-D8F5399B3A8F@objectstyle.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <785DF4E7-7B57-403A-956D-E382D8D7E3A0@fsys.se>
	 <D9785385-3D2B-41A9-9082-D8F5399B3A8F@objectstyle.org>

The performance of this may not work for your specific situation, but
my java web application allows for the possibility that some external
process may update the database like this:

I created a table: LAST_EXTERNAL_UPDATE with two fields:

ID
LAST_CHANGED

Any external process changes the LAST_CHANGED timestamp field whenever
something updates.

I created an alternative class to
org.apache.cayenne.conf.BasicServletConfiguration and changed
"getDataContext()" to check for external updates before returning the
dataContext.


        try
        {
            checkForExternalUpdates(dataContext, session);
        }
        catch (CayenneRuntimeException cayenneRuntimeException)
        {
            // If it failed, it probably failed during the database
read, so ignore
            // REPORT ERROR code here
        }


    public static void checkForExternalUpdates(DataContext
dataContext, String identityString, HttpSession session)
    {
        List lastExternalUpdateList = // FETCH YOUR
LAST_EXTERNAL_UPDATE RECORD CODE HERE;

        boolean willInvalidate = false;

        if (1 != lastExternalUpdateList.size())
        {
            // database error -- zero or multiple LastExternalUpdate
objects found
            // REPORT DATABASE ERROR CODE HERE
        }

        LastExternalUpdate latestExternalUpdateObject =
(LastExternalUpdate)lastExternalUpdateList.get(0);

        if (null == latestExternalUpdateObject)
        {
            willInvalidate = false;
        }
        else
        {
            final Date lastSessionExternalUpdateDate =
(Date)session.getAttribute("lastSessionExternalUpdateDate");

            Date latestChangedDate =
latestExternalUpdateObject.getLastChanged();
            if (null == latestChangedDate)
            {
                willInvalidate = false;
            }
            else if (null == lastSessionExternalUpdateDate)
            {
                willInvalidate = true;
            }
            else
            {
                if (lastSessionExternalUpdateDate.before(latestChangedDate))
                {
                    willInvalidate = true;
                }
                else
                {
                    willInvalidate = false;
                }
            }

            session.setAttribute("lastSessionExternalUpdateDate",
latestChangedDate);
        }

        if (willInvalidate)
        {
            dataContext.invalidateObjects(dataContext.getObjectStore().getObjects());
        }
    }

Instead of a timer, this method checks every time you request the
session datacontext.   And it also invalidates everything if something
changed.  You can probably be far more selective than that.

On 5/5/08, Andrus Adamchik <andrus@objectstyle.org> wrote:
> for java-to-java invalidation I successfully used OSCache with JGroups. For
> non-java apps that change the data there are a few options:
>
>  1. A private URL in a webapp that a script can access that would cause
> cache invalidation
>  2. A timer local to the app that checks a special table in DB that is
> populated by the script on data changes.
>  3. A timer running in a remote Java app that checks a DB table, and then
> notifies another app with JGroups.
>  4. etc.
>
>  Andrus
>
>
>
>  On May 5, 2008, at 11:21 AM, Andreas Pardeike wrote:
>
>
> > Hi,
> >
> > I have an web application that serves html pages from a databases.
> > That database is manipulated from a perl program that runs from
> > within a proftpd ftp server. As a result, users can upload their
> > html pages via ftp and the web application displays them.
> >
> > I want to cache the page queries in the web application but have
> > not found a good way to invalidate a certain page in the cache once
> > a user uploads a modified version of it.
> >
> > I use:
> >
> > - Tomcat on Linux
> > - Tapestry 5
> > - Cayenne 3
> > - Mysql 5
> > - Custom mod_exec perl script in proftpd
> >
> > What is the best approach here?
> >
> > /Andreas Pardeike
> >
> >
>
>