> Somehow the response is cached.  I tried using mod_expires and
> mod_header to influenue the Cache-control header (max_age=0) but
> Firefox is still loading the cached data and not loading the updated
> date?

> How to avoid this?  How to setup the cache mechanism properly?

> > Somehow the response is cached.  I tried using mod_expires and
> > mod_header to influenue the Cache-control header (max_age=0) but
> > Firefox is still loading the cached data and not loading the updated
> > date?

> > How to avoid this?  How to setup the cache mechanism properly?

> wxJS doesn't cache anything. The only way you can cache some values is
> by adding properties to the 'wxjs' global object. The next release will
> have a memcached client.
> I suppose it is an Apache thing.

> Franky.

> This is what I have now, which doesn't work.  The server keeps sending
> the cached data?  I do have SSL running, but I don't think that's the
> cause of the problem.

> Did you have the set the MIME type for wxjs?

> <Directory />
>     Options FollowSymLinks
>     AllowOverride None
>     Order deny,allow
>     Deny from all
>     Satisfy all
> #    ExpiresActive On
> #    ExpiresDefault A5
>     <FilesMatch "\.wxjs$">
>         Header set Cache-Control "no-cache, no-store"
>         Header set Expires "0"
>         Header set Pragma "no-cache"
>     </FilesMatch>
> </Directory

> On Aug 31, 12:39 am, Franky Braem <franky.br...@gmail.com> wrote:

> > whoisterence...@hotmail.com wrote:
> > > I have a wxjs which I want to run each time it is requested.

> > > Somehow the response is cached.  I tried using mod_expires and
> > > mod_header to influenue the Cache-control header (max_age=0) but
> > > Firefox is still loading the cached data and not loading the updated
> > > date?

> > > How to avoid this?  How to setup the cache mechanism properly?

> > wxJS doesn't cache anything. The only way you can cache some values is
> > by adding properties to the 'wxjs' global object. The next release will
> > have a memcached client.
> > I suppose it is an Apache thing.

> > Franky.

> However I am also using wxjs_DB and when I update my database, the
> data is not reflected in the response.  Seems mod_wxjs+wxjs_DB is
> caching my query results.

> So I tried to run the same code using command line wxjs and the data
> is updated?

> Any ideas?  How mod_wxjs+wxjs_DB is caching the query results?  Maybe
> when the sql connection is opened and not closed, the same SQL
> statements return cached results?

> According to wxDB/main.cpp, the connection is only close when:

>            case DLL_PROCESS_DETACH:
>            wxDbCloseConnections();
>                    break;
>            }

> Not sure if DLL_PROCESS_DETACH occurs with  mod_wxjs+wxjs_DB running
> on Apache?

> > However I am also using wxjs_DB and when I update my database, the
> > data is not reflected in the response.  Seems mod_wxjs+wxjs_DB is
> > caching my query results.

> > So I tried to run the same code using command line wxjs and the data
> > is updated?

> > Any ideas?  How mod_wxjs+wxjs_DB is caching the query results?  Maybe
> > when the sql connection is opened and not closed, the same SQL
> > statements return cached results?

> > According to wxDB/main.cpp, the connection is only close when:

> >            case DLL_PROCESS_DETACH:
> >            wxDbCloseConnections();
> >                    break;
> >            }

> > Not sure if DLL_PROCESS_DETACH occurs with  mod_wxjs+wxjs_DB running
> > on Apache?

> Can you try to use commitTrans:http://www.wxjavascript.net/db/classes/wxDb.html#commitTrans?
> A script is run in it's own context and when that is cleaned up (after
> each script has run), the destructor of wxDb is called.
> The database is closed there.

> Franky.

> On Sep 4, 2:44 am, Franky Braem <franky.br...@gmail.com> wrote:

> > whoisterence...@hotmail.com wrote:
> > > I did some experimentations and I changed some data in the wxjs code
> > > and it's immediately reflected in the response, so it seems the
> > > response is not cached.

> > > However I am also using wxjs_DB and when I update my database, the
> > > data is not reflected in the response.  Seems mod_wxjs+wxjs_DB is
> > > caching my query results.

> > > So I tried to run the same code using command line wxjs and the data
> > > is updated?

> > > Any ideas?  How mod_wxjs+wxjs_DB is caching the query results?  Maybe
> > > when the sql connection is opened and not closed, the same SQL
> > > statements return cached results?

> > > According to wxDB/main.cpp, the connection is only close when:

> > >            case DLL_PROCESS_DETACH:
> > >            wxDbCloseConnections();
> > >                    break;
> > >            }

> > > Not sure if DLL_PROCESS_DETACH occurs with  mod_wxjs+wxjs_DB running
> > > on Apache?

> > Can you try to use commitTrans:http://www.wxjavascript.net/db/classes/wxDb.html#commitTrans?
> > A script is run in it's own context and when that is cleaned up (after
> > each script has run), the destructor of wxDb is called.
> > The database is closed there.

> > Franky.

> It caches the result unless the connection is closed.  Is there other
> ways to close the connection?

> > Looks like Foxpro ODBC problem:http://support.microsoft.com/kb/261267

> > It caches the result unless the connection is closed.  Is there other
> > ways to close the connection?

> I will re-add the close method. I removed it, because it can create
> problems when you still use db-related classes while the database is
> closed.

> Franky.

> I tried adding the wxDbCloseConnections(); to a newly created
> wxdb.close(), but looks like the problem is not solved.  Not sure if I
> added this function into db.h and db.cpp correctly?  But the module
> loads with mod_wxjs and I can pull the date online, but the data is
> still not updated as previously mentioned.

> I hope once I can close the odbc connection this problem would go
> away, but at the sametime, I am wondernig if something else is
> happening offline with wxjs+wxdb which doesn't happen with mod_wxjs
> +wxdb?  Any ideas?

> Regards
> Terence

> > I tried adding the wxDbCloseConnections(); to a newly created
> > wxdb.close(), but looks like the problem is not solved.  Not sure if I
> > added this function into db.h and db.cpp correctly?  But the module
> > loads with mod_wxjs and I can pull the date online, but the data is
> > still not updated as previously mentioned.

> > I hope once I can close the odbc connection this problem would go
> > away, but at the sametime, I am wondernig if something else is
> > happening offline with wxjs+wxdb which doesn't happen with mod_wxjs
> > +wxdb?  Any ideas?

> > Regards
> > Terence

> I have written the close method as follows:

> JSBool Database::close(JSContext *cx,
>                        JSObject *obj,
>                        uintN WXUNUSED(argc),
>                        jsval* WXUNUSED(argv),
>                        jsval* WXUNUSED(rval))
> {
>     Database *p = GetPrivate(cx, obj);
>     if ( p == NULL )
>         return JS_FALSE;
>     wxDb *db = ((DatabaseRefData *)p->GetRefData())->GetDB();

>     db->Close();

>     return JS_TRUE;

> }

> The difference between mod_wxjs and wxjs shell is that the shell process
> immediately ends and cleans up the js runtime.
> This is not the case in mod_wxjs, because the apache process is kept
> alive. But all the classes and variables created in a server-side script
> are created on a global object that is new for every script execution.
> So the wxDb should be closed when the context is destroyed. Is your
> database stored in a variable declared with the var-keyword? Because
> there is a subtle life-time difference when you don't use the 'var' keyword.

> Franky.

> I tried db->Close(), but it crashes wxjs.exe.  wxDbCloseConnections
> doesn't crash, but it query data is still being cached.

> > I tried db->Close(), but it crashes wxjs.exe.  wxDbCloseConnections
> > doesn't crash, but it query data is still being cached.

> This is what the assert tells us:

> 19:34:23: Debug: ..\..\src\common\db.cpp(1749): assert "nTables == 0"
> failed in
> wxDb::Close().

> The problem is there are still tables open when close is called. This
> doesn't happen when the script ends (without calling close), because the
> close will only be called when all tables are destructed. A table holds
> a reference to a database, and releases it when it is destructed.

> This is what the wxWidgets manual says: Any wxDbTable instances which
> use this connection must be deleted before closing the database
> connection. Now in JavaScript you don't have control of the destruction
> of objects. So the close method is no solution for this problem.

> I will try to debug more and see if the database is closed when the
> script is ended in Apache.

> Franky.

> I used ODBC Tracer log to check whether there is a difference between
> mod_wxjs and wxjs shell ODBC Calls to the database, they are the same
> except one thing mod_wxjs doesn't seem to repeat the calls when I
> request the script, this prove the bug about closing connection is
> correct.  Also, the log file is locked until I kill apache, I think
> it's very clear something between wxDB and the ODBC is caching the
> result or not openning a new connection.

> I think you're in the right direction, first delete the table and then
> close the connection.

> On Sep 11, 1:46 am, Franky Braem <franky.br...@gmail.com> wrote:

> > whoisterence...@hotmail.com wrote:
> > > Frank,

> > > I tried db->Close(), but it crashes wxjs.exe.  wxDbCloseConnections
> > > doesn't crash, but it query data is still being cached.

> > This is what the assert tells us:

> > 19:34:23: Debug: ..\..\src\common\db.cpp(1749): assert "nTables == 0"
> > failed in
> > wxDb::Close().

> > The problem is there are still tables open when close is called. This
> > doesn't happen when the script ends (without calling close), because the
> > close will only be called when all tables are destructed. A table holds
> > a reference to a database, and releases it when it is destructed.

> > This is what the wxWidgets manual says: Any wxDbTable instances which
> > use this connection must be deleted before closing the database
> > connection. Now in JavaScript you don't have control of the destruction
> > of objects. So the close method is no solution for this problem.

> > I will try to debug more and see if the database is closed when the
> > script is ended in Apache.

> > Franky.

> JSBool Table::close(JSContext *cx, JSObject *obj, uintN argc, jsval
> *argv, jsval *rval)
> {
>     Table *p = Table::GetPrivate(cx, obj);
>     if ( p == NULL )
>         return JS_FALSE;

>    delete p->m_table;
>    return JS_TRUE;
> }

> This crashes wxjs shell.  Not sure how to delete wxDbTable ?  :)

> > JSBool Table::close(JSContext *cx, JSObject *obj, uintN argc, jsval
> > *argv, jsval *rval)
> > {
> >     Table *p = Table::GetPrivate(cx, obj);
> >     if ( p == NULL )
> >         return JS_FALSE;

> >    delete p->m_table;
> >    return JS_TRUE;
> > }

> > This crashes wxjs shell.  Not sure how to delete wxDbTable ?  :)

> Two corrections: you must delete p instead of p->table and you must set
> the private data of object to NULL, because the JS destructor will try
> to delete the table also.
> So do this:

> JSBool Table::close(JSContext *cx, JSObject *obj, uintN argc, jsval
> *argv, jsval *rval)
> {
>     Table *p = Table::GetPrivate(cx, obj);
>     if ( p == NULL )
>         return JS_FALSE;

>         delete p;
>         JS_SetPrivate(cx, obj, NULL);
>         return JS_TRUE;

> }

> Now we have to check p in every function, because this will crash the
> shell also.

> Franky.