Caroline, thank you.
So, we are inching our way to a working solution. The steps I can see
in front of me are these:
1. We were getting an SDO_UnsupportedOperationException with the text
"Adding Properties after type completed" on a fairly simple test case
that I thought ought to have worked. We need to get to the bottom of
this. It is some interaction between the caching and addTypes. It
might be that we can just sidestep it but I would like to understand
it a little better first.
2. Next I will reorganise the places in the SCA PHP code where we used
to do create() followed by addTypes(file) to just do the single call
to create() with an array. I will need to generate some kind of hash
of the set of filenames to use as a key to keep hold of the cached
data factory. This, with the caching code that I have already put in
should be enough so that a second and subsequent call to a component
should find all the types that that component uses already loaded. I
hope this will be enough to get Ben Barringer going.
3. Then I will have to tackle invalidating the cache when the files
change. I suppose I will check the timestamps on the files. I think
this is going to be harder than you might think. The reason is that
the pathnames that I get passed in to the C code, if relative, are
relative to the PHP working directory and not to the C working
directory (I blogged about this on the developerWorks blog a while
ago). This means that I cannot directly use within the C code any
relative pathnames I have been given from PHP. I will have to find a
way to call the PHP routines to check the file timestamps.
Also, I am never sure whether it is enough to just check the file
timestamps. I wonder if I ought to open the file and do a hash of the
contents, just to make sure that the contents have not changed.
I am not sure how long this is going to take. I know Ben wanted an
outlook for when we might complete. I am going to try to complete the
first two steps i.e. running without invalidation by the end of next
On Mar 21, 3:09 pm, "cem" <[EMAIL PROTECTED]> wrote:
> I've made a change to the signature of SDO_DAS_XML::create(). Instead
> of a single path to a schema file, this now takes an array of paths to
> schema files. This is checked into the BUZZARD branch.
> The idea here is that people can in most cases avoid the problem of
> addTypes(), by instead making a single call to create() with all the
> required schema files at one go.
> Your prototype caching code is still in place, but currently only gets
> involved when create() is called with the old-style signature. I've
> checked that it still works in that case. Did you have a design in
> mind for how to update the table key to represent a set of schema
> I know this isn't a complete solution. Adding the schemas all at once
> will be useful, but I think there are still cases where addTypes()
> will be needed later. When that happens, I would like to be able to
> clone the DataFactory, that is, to make a copy without having to re-
> read the schema files, so that the additional types can be added and
> the original factory kept unchanged. But to do this would require a
> clone function that doesn't currently exist in the underlying Tuscany
> On Feb 27, 3:54 pm, "Matthew Peters" <[EMAIL PROTECTED]>
> > Given how infrequently a given WSDL or schema file changes, it makes
> > no sense to pound away on it building the SDO model from it on every
> > request. We ought to cache the result of doing that: caching either
> > the SDO model or the data factory that contains that model.
> > There are two approaches we could take:
> > 1. We could try to keep the interface unchanged, so all PHP code
> > continues to use just SDO_DAS_XML::create() and addTypes() ...
> > 2. We could put in some explicit caching that is visible at the PHP
> > level and is controlled by the SCA for PHP code or even the
> > application code somehow
> > There are, independently, a couple of possibilities for where and what
> > we cache. Two options seem to be:
> > A. we could serialise the SDO model out to a file and read it back
> > in when needed ...
> > B. we could hold on to the data factory within memory, within the
> > sdo_php extension.
> > We examined option A, write the XML DAS to a file. What we found is
> > that there is logic in the XML DAS to cache the model to a file
> > already, but it caches as schema, so reading it back in just gets us
> > back into loading schema again. So, we would need to come up with a
> > format - binary or human-readable - that is quicker to re-read. We
> > imagine by the way that anything cached in this way does not have to
> > last very long. We would not want to get into the situation of trying
> > to have file formats that were compatible across different releases of
> > SDO, or between different platforms, or anything fancy.
> > So, we have concluded that the simplest thing to do is probably to
> > cache in memory, option B.
> > Now look at the options 1. vs 2. i.e the interface. The ideal is
> > probably to keep the interface unchanged, but in the meantime we might
> > want to do something quicker to implement as a stop-gap, even if it
> > puts a bit of responsibility into the SCA code.
> > The thing that worries me about option 1. comes about because we have
> > addTypes(). If you do create(), followed by a string of addTypes(), at
> > what point do you consider the data factory/model finished? And then
> > they come back issuing the same string of create() and addTypes()
> > (hence wanting the exact same model), how do you spot that and use the
> > cached one? It seems to me that that needs a solution. Perhaps allow
> > create() to take an array of types, and make that array the the key to
> > the cached DAS?
You received this message because you are subscribed to the Google Groups
To post to this group, send email to firstname.lastname@example.org
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at