[phpsoa] Re: Suggest we cache the SDO model somehow
I wonder what happened to the post I just sent
... forget the words I said last time, since Caroline said it had to
be an object not an array I proposed the following interface:
$key = // calculate this in some way based on the xsd or xsds to be
used.
if (SDO::cache-containsKey($key)) {
$das = SDO::cache-get($key);
} else {
$das = SDO_DAS_XML::create(path to the xsd);
SDO::cache-put($das, $key);
}
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[phpsoa] Re: Suggest we cache the SDO model somehow
Graham Charters wrote: One *real* comment: I think we should be getting into the habit of using magic method-style things which appear on the SDO interface (and also our proxy interfaces) to reduce the risk of clashes with the business interfaces (in this case the properties of an SDO, and in the case of our proxies it would be the service methods). Graham, I quite agree that the SCA proxies should not be cluttered up with service methods, but I'm not quite sure why you mentioned this in this particular thread - are you unhappy with the interface Matthew proposed? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[phpsoa] Re: Suggest we cache the SDO model somehow
On 5 Jun, 10:36, Caroline Maynard [EMAIL PROTECTED] wrote: Graham Charters wrote: One *real* comment: I think we should be getting into the habit of using magic method-style things which appear on the SDO interface (and also our proxy interfaces) to reduce the risk of clashes with the business interfaces (in this case the properties of an SDO, and in the case of our proxies it would be the service methods). Graham, I quite agree that the SCA proxies should not be cluttered up with service methods, but I'm not quite sure why you mentioned this in this particular thread - are you unhappy with the interface Matthew proposed? I mentioned the proxies as one of the two areas where we need to keep the interface clean (the other was SDO). I mentioned SDO because the cache appears to be on the SDO interface in Matthew's example code (unless I've misunderstood). --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[phpsoa] Re: Suggest we cache the SDO model somehow
Graham Charters wrote: I mentioned the proxies as one of the two areas where we need to keep the interface clean (the other was SDO). I mentioned SDO because the cache appears to be on the SDO interface in Matthew's example code (unless I've misunderstood). No, you haven't misunderstood, I just haven't quite grasped why adding a property to the extension would be a problem (actually I think it would for various reasons have to be an object rather than a pure array as originally proposed to Matthew - sorry for misleading you - but that's irrelevant to this question). It doesn't affect the SDO_DataObject interface. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[phpsoa] Re: Suggest we cache the SDO model somehow
Matthew, one more thing I'd like to add to this discussion, which struck me as I was listening to Brian Shire's excellent presentation at php|tek (http://tekrat.com/wp/talks/phptek2007/[EMAIL PROTECTED]). There are already several caching solutions for php, in particular APC, also memcache and some proprietary ones, including Zend's. APC is mature and very configurable. So IMHO when SCA needs to cache some data, it should be checking to see if something suitable is installed, and exploiting it, not inventing something unnecessarily. I realise this won't help directly with the problem here, because the model must be cached within the SDO extension rather than in SCA, because of the Tuscany dependency, but I just wanted to record this in case it's useful in the future. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[phpsoa] Re: Suggest we cache the SDO model somehow
Graham Charters wrote:
Ah, I think I have misunderstood, and it's the subtle (at least to my
brain) distinction between SDO and SDO_DataObject. What do you mean
by adding a property to the extension? I'm not aware of an
interface we expose called SDO so jumped to the conclusion that this
was the SDO_DataObject. Why would this not be on the SDO_DAS_XML?
Actually I agree, I think it would be better for the cache to be a
static property of the SDO_DAS_XML class rather than an extension
global. Still doesn't affect the SDO_DataObject interface, though.
So, if you do :
php --rc SDO_DAS_XML
it would appear in that currently empty array :
- Static properties [0] { }
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[phpsoa] Re: Suggest we cache the SDO model somehow
Bad form to reply to my own post, but just after I sent it I saw this thread in the internals mailing list: http://thread.gmane.org/gmane.comp.php.devel/43094 so we shouldn't use APC to cache SCA objects without giving some thought to how they get serialized. That's probably not too surprising. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[phpsoa] Re: Suggest we cache the SDO model somehow
I just checked in to DUNLIN a temporary change so that the ebaysoap
binding uses the caching of the data factory. Specifically, what I did
was:
1. enable the caching in the sdo extension when the special two-
argument version of SDO_DAS_XML::create is used
2. make the table of cached data factories only one deep ie only allow
one cached data factory
3. make the ebaysoap binding the only place in SCA where we use the
two-argument create
This is a temporary state of affairs but probably how it will go out
in the next release.
What I want to do long-term is to expose the table of cached das's as
a proper PHP associative array which is a static member of the SDO
class, then anyone can use it any way they see fit. The logic to use
it would then look something like:
$key = // calculate this in some way based on the xsd or xsds to be
used.
if (array_key_exists(SDO::cache($key)) {
$das = SDO::cache[$key];
} else {
$das = SDO_DAS_XML::create(path to the xsd);
SDO::cache[$key] = $das;
}
Once the table of cached das's is in user space then people can decide
about what to cache when, and when to invalidate entries and so on.
Which is more or less what Ben suggested in the first place...
Matthew
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[phpsoa] Re: Suggest we cache the SDO model somehow
Sorry all that I am really late in this conversation (only a few weeks behind). Been meaning to respond but always get distracted by something (think I got ADD or something) :/. I think I had mentioned this before but I really think there needs to be 2 (at least) modes to this. In my case, our company controls the servers, so I would want to be able to set my own key to be used for caching. If other apps/departs want to use my schemas I would share the key with them and everyone would use the same. This really wont work in the shared hosting environment though. I bet in almost all those cases the hosting provider would not want caching enabled (otherwise not install the extension). They dont want one customer hogging memory here. In this case the per request caching might be applicable (if you are even considering this type of caching). So in short, it would be nice for at the minimum of system caching (shared between processes) and an option to disable completely. Nice to haves would be option for per request or file based caching like ext.soap. I know I just asked for everything here but at the minimum a way to disable caching on a server level (ini option) is definitely needed. Hope I am not too far behind and mentioning things already implemented :) Rob On 3 Apr, 11:12, Matthew Peters [EMAIL PROTECTED] wrote: Yes, exactly right. The scope is intended to be module init to shutdown, and across all callers. I don't really know how I could do otherwise - a per-request cache would be throwing away all the benefit. Of course you have worried me now. If the keys are chosen poorly - for example every call chooses key my_first_key or suchlike - then that is a recipe for disaster. The key needs to correspond to the set of types that are loaded into that DAS: the keys must be chosen so that if the model is different, so is the key. I can't enforce that, of course, all I can do is use it that way throughout the SCA code. On Mar 23, 1:52 pm, cem [EMAIL PROTECTED] wrote: This discussion thread hasn't explicitly spelled out the scope of the cache, but I've been assuming that we're intending it to endure from module init to module shutdown. In other words, depending on the SAPI, the cache entries may be available to multiple independent SCA programs, sequentially and simultaneously. Did I get this wrong? I can see how the interface you describe would work for a request-scoped or possibly thread-scoped cache. But it doesn't feel right to me to hand out the task of key management to uncoordinated applications. Imagine if everyone used the same key string that's in the example code snippet :-) Please put me right. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[phpsoa] Re: Suggest we cache the SDO model somehow
Yes, exactly right. The scope is intended to be module init to shutdown, and across all callers. I don't really know how I could do otherwise - a per-request cache would be throwing away all the benefit. Of course you have worried me now. If the keys are chosen poorly - for example every call chooses key my_first_key or suchlike - then that is a recipe for disaster. The key needs to correspond to the set of types that are loaded into that DAS: the keys must be chosen so that if the model is different, so is the key. I can't enforce that, of course, all I can do is use it that way throughout the SCA code. On Mar 23, 1:52 pm, cem [EMAIL PROTECTED] wrote: This discussion thread hasn't explicitly spelled out the scope of the cache, but I've been assuming that we're intending it to endure from module init to module shutdown. In other words, depending on the SAPI, the cache entries may be available to multiple independent SCA programs, sequentially and simultaneously. Did I get this wrong? I can see how the interface you describe would work for a request-scoped or possibly thread-scoped cache. But it doesn't feel right to me to hand out the task of key management to uncoordinated applications. Imagine if everyone used the same key string that's in the example code snippet :-) Please put me right. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[phpsoa] Re: Suggest we cache the SDO model somehow
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 -~--~~~~--~~--~--~---
