Hi!
I'm afraid we are hit by some nasty drawbacks of Spectra 1.5's new
SERVER-scope content object caching:
We have several "system-level" objects in our database - mainly used for
internal configuration.
If we create a new Application (within a new Object-DB), we migrate these
objects.
It is possible that the content inside such objects is changed in one DB,
but these changes shouldn't reflect
in in the other one. Because the SERVER-scope cache just uses
server.cfa.objectCache.stObjects[oid],
that is NO REFERENCE to DATASOURCE and/or APPLICATIONID, we get the same
data in both applications ;-(
I know that
(a) normally "having the same UUID" means "being the same object" and
(b) that there is a "bUseCache=FALSE"-option for cfa_COget.
But
ad a)
it really makes sense to have the same UUID for the same object with
(slithly) different content.
This holds especially for "system-level" objects, but even "classical
content objects", e.g. a news,
may differ in the context of SYNDICATION: I use syndication to share a news
between two local apps, but
I add/change some data in one app ...
ad b)
cfa_COData internally uses cfa_COget (without this setting) and so I can get
data in the cache
through the "back-door".
Does anyone have similar problems, and even more important, some way to
solve them ?!?
Basicly we always suffered a little from the fact that Spectra does not
provide any mechanism
to separate (and share) data between applications other than using different
DBs (and syndication between them)
We found that a little restrictive in the beginning (dreaming for a kind of
additional TABLE-columns throughout
all Spectra-Tables like MAND in SAP R/3 used for that kind of separation
....), but learned to
live with it. Therefore it is vital that the DB can really be used for
segmentation, i.e.
VERITIY-Collection, CACHE, etc. must take care about the DB-frontiers.
Regards,
Peter Trumpp
conceptware ag
