P
phil.a.jenkins
Hopefully someone can provide a solution to this rather annoying
problem - we have a Cocoon pipeline which ends thus:
<!-- build the sql for insert and final stage of select -->
T1 <map:transform type="xslt" src="stylesheets/buildsql2.xsl"/>
<!-- run the sql -->
<map:transform type="sql">
<map
arameter name="*****" value="****"/>
</map:transform>
<!-- build the response -->
T2 <map:transform type="xslt" src="stylesheets/buildresult.xsl"/>
<!-- send the response -->
<map:serialize/>
The SQL queries in Transform T1 execute either SELECT or INSERT queries
on a large meta-database, so the following performance characteristics
apply:
1. SELECT statements take a long time to
'render' to the final xml result- i.e. Transform T2.
2. INSERT statements take a long time to
execute in the first place i.e. Transform T1.
Now, if transform T2 takes a long time to execute (sometimes in the
region of hours), there is no problems, the client will happily sit and
wait for the data. Transform T1 on the other hand will cause the squid
proxy (though which cocoon is accessed) to give a timeout error back to
the client after x mins. The database INSERT however completes
succesfully, regardless of this error.
It seems apparent from this situation that a cocoon serializer will
'stream' data back to the client through the proxy - but the transform
steps must wait for well-formed XML before contacting the client. Is
there any way of keeping a connection 'busy' while waiting for this
transform (T1) to complete?
PS Sadly we cannot change the timeout limit on the Squid proxy, which
would have rendered this message redundant.
problem - we have a Cocoon pipeline which ends thus:
<!-- build the sql for insert and final stage of select -->
T1 <map:transform type="xslt" src="stylesheets/buildsql2.xsl"/>
<!-- run the sql -->
<map:transform type="sql">
<map
arameter name="*****" value="****"/></map:transform>
<!-- build the response -->
T2 <map:transform type="xslt" src="stylesheets/buildresult.xsl"/>
<!-- send the response -->
<map:serialize/>
The SQL queries in Transform T1 execute either SELECT or INSERT queries
on a large meta-database, so the following performance characteristics
apply:
1. SELECT statements take a long time to
'render' to the final xml result- i.e. Transform T2.
2. INSERT statements take a long time to
execute in the first place i.e. Transform T1.
Now, if transform T2 takes a long time to execute (sometimes in the
region of hours), there is no problems, the client will happily sit and
wait for the data. Transform T1 on the other hand will cause the squid
proxy (though which cocoon is accessed) to give a timeout error back to
the client after x mins. The database INSERT however completes
succesfully, regardless of this error.
It seems apparent from this situation that a cocoon serializer will
'stream' data back to the client through the proxy - but the transform
steps must wait for well-formed XML before contacting the client. Is
there any way of keeping a connection 'busy' while waiting for this
transform (T1) to complete?
PS Sadly we cannot change the timeout limit on the Squid proxy, which
would have rendered this message redundant.