Sadly, I seem to have lost the post that I spent half an hour composing earlier today...I thought Google said it had been successfully sent but it hasn't appeared yet...so, I will be more succinct this time. I looked through the posts so far from Ben, Rob and Simon, thought about them, and weighed up the pros and cons of the two approaches (1) cache and do the invalidation by timestamp and (2) require user involvement to tell us when to cache and when to invalidate.
The essential difficulty about caching and invalidating by timestamp is that xsds may use include to point to other files. I cannot tell if these other files have changed. Hence invalidation by timestamp is dodgy. Even if I open the file and look at the contents that is not enough - I would need to parse and follow the links to included files. That's horrible. Add to that the bother caused by the fact that relative pathnames the extension gets are relative to the PHP cwd and not to the C cwd, so that C code cannot necessarily just stat what it is given, and I would have to work out how to call the PHP routines to check timestamp, and invalidating by timestamp is unattractive. I prefer to put it somewhat under user control. Here is my proposed use case and interface: // first time through... $xmldas = SODO_DAS_XML::create(<array of filenames>,<key>); // first time through it creates and stores under the given key // use the das // ...then in a later request, the call looks the same but the behaviour is different $xmldas = SODO_DAS_XML::create(<array of filenames>,<key>); // ... the same call this time the das is retrieved based on the key I much prefer to generate the key in PHP space by the way. If I have to do it in C then I know I will write a lot of buggy code to xor the filenames together which creates a code, test and maintenance burden. If I do it in PHP space (for our case it will be in the SCA code) I can do it in a couple of lines of PHP. The interface is a little odd, but it is to do with the fact that in our PHP code there is no equivalent to a first-time-through flag, so the call has to look the same each time. The code inside the extension will be something like: if (<key> is not in table) generate new data factory from file names store in table under <key> else retrieve stored data factory using <key> put data factory into das and return so, if they want the use on the second time through could call create(null, <key>). We will not do this in the SCA code. We will also need to introduce an explicit invalidate: SDO_DAS_XML::invalidateSavedDataFactoryTableEntry(<key>); perhaps OK, open for comments. On Mar 21, 5:20 pm, "Matthew Peters" <[EMAIL PROTECTED]> wrote: > 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 > week. > > Matthew > > On Mar 21, 3:09 pm, "cem" <[EMAIL PROTECTED]> wrote: > > > Matthew, > > > 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 > > files? > > > 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 > > library. > > > On Feb 27, 3:54 pm, "Matthew Peters" <[EMAIL PROTECTED]> > > wrote: > > > > 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 "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~----------~----~----~----~------~----~------~--~---
