Myna.Cache Question

[Tony Zakula]

Working on an Ecommerce app and still wondering the best place to
store application settings which will be used on every request. If I
store them in a file and they get included with Myna.include(), then
they will be stored in memory after the first run. However, I will
have an admin that will be able to change settings so then the web app
will need write access to the settings. Not the end of the world, but
still a possible security concern. If I store them in the database,
it makes administration easier and more secure, but I would hate to
pound the database on every request when many of these settings will
not change for possibly days on end. I could make it a two step
process of updating the database and putting them on disk, but that
seems more error prone.

What about using Myna.Cache? These settings would basically be simple
Json objects or query results like the example in the docs. Would
that basically be the same as the Myna.include as far as speed and
being in memory? It would be available to all requests? Any side
affects of this? I could also make it where the caching can be turned
on and off.

Thanks!

Tony Zakula

[Mark Porter]

The real issue here is the security requirement. Myna is not designed
for firewalling applications from each other. Writing to a database
has the same problem, unless you want to give the admin app read-write
access and app read-only access. Even then the app just needs to use
the writable DS. If someone can alter your code server-side it is
basically "game over".

If you are not trying to protect against an attacker that can alter
your code, you can use onApplicationStart() to load your settings via
$application.set(). Since the $application scope is shared, your admin
action can update this. If you want completely seperate apps for admin
and runtime, then storage in $server might make sense. There is also
the Myna.Event[1] system which will allow you to notify any number of
listeners on different servers that a settings change has happened so
that they can update local settings stores. Finally
Myna.Cluster.getMap()[2] provides a cross-instance global memory
store.

It all depends on the scope you need to operate on. Normally I keep
admin functions with the app so that they operate inside the same
$application and either load settings on the $application instance on
every request, or via $application.set() if I think I'll need to
modify them at runtime.

[1]:http://www.mynajs.org/shared/docs/js/libOO/files/Event-sjs.html
[2]:http://www.mynajs.org/shared/docs/js/libOO/files/Cluster-sjs.html#Myna.Cluster.getMap
----------------------------------------------------------
Mark Porter

Myna JavaScript Application Server
Easy web development with server-side JavaScript
http://www.mynajs.org

> --
> You received this message because you are subscribed to the Google Groups "MynaJS-General" group.
> To post to this group, send email to mynajs-...@googlegroups.com.
> To unsubscribe from this group, send email to mynajs-genera...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/mynajs-general?hl=en.
>
>

[Tony Zakula]

Okay, you kind of lost me a little here. :-) I can see I did not
clearly explain. We may be talking about the same thing, but let me
run down what is in my head.

My admin app and web app are running in the same app. Basically just
a folder difference. Although, that is an intriguing idea to separate
them. For getting started sake, lets assume we are not going to run a
cluster. Just one web app right now.

My only goal at this point was to possibly eliminate one extra hit to
the database for every request coming in to the application for
optimization purposes. Each request will need the application
settings to know how to handle the request properly. If a complicated
product page is going to require at least a couple of queries, and
another part of the page requires a query, it seems like hits to the
database are adding up fast here for each request.

The admin app would only update the database or file. It would not
change them in memory for running requests.

<snip>load settings on the $application instance on every request</snip>
So hit the database every request.

<snip>$application.set()</snip>
This is shared scope in memory on the server, shared between all
requests. After reading the docs a little more, this would stop a
database hit, and accomplish what I want. I forgot that the items we
discussed before about application scope will not be an issue because
I am working inside my app now, and not on a server level.

If I make a factory method on one of my classes for setting
application scope, I can always switch to a more cluster friendly
environment.

Please confirm if I am misled anywhere. :-) Thanks.

Tony Z

[Mark Porter]

Actually I think you've got it. Make your settings changes via a
class, an you can always change where they are stored later. load your
setting ins onApplicationStart() via $application.set(), and then
update via set() when you make changes. Setting stay cached.

----------------------------------------------------------
Mark Porter

Myna JavaScript Application Server
Easy web development with server-side JavaScript
http://www.mynajs.org