Richard, et al.,
Any reference to any object in a stack (or the stack itself) that
includes its file path name (the long name, the long id) will place
it in memory. You might consider that. We had that bite us several
times with Constellation and Galaxy in managing our tabs for objects.
Best,
Jerry Daniels
Makers of Galaxy 1.5
http://www.daniels-mara.com/new_in_galaxy_1_5.htm
On Oct 30, 2006, at 10:48 AM, Richard Gaskin wrote:
I'm working with a client on a system that makes extensive use of
data stored in custom properties.
I had been under the impression that as long as the stack
containing the data has its destroyStack set to true, and as long
as we don't open the stack, everytime we access its properties
we're getting it fresh from disk rather than from cached memory.
Is that correct?
We're in the process of pinning down some anomalies in our system
which would seem to suggest that accessing properties can cause a
stack to remain in memory such that subsequent accesses are
obtained from memory rather than from disk.
I would love to be wrong, as it would complicate our system to have
to manually purge each stack before accessing it.
And as for that purging, in the absence of a purge command there is
the workaround of using the delete command, but at the moment my
memory's flakey: does using "delete stack" merely purge the stack
but not delete the actual stack if it's a mainStack, or if it's a
substack?
And once we confirm which type of stack we can safely purge without
deleting it using the "delete stack" command, what method do we use
to purge stacks of the other kind?
--
Richard Gaskin
Fourth World Media Corporation
___________________________________________________________
[EMAIL PROTECTED] http://www.FourthWorld.com
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
