snip/
Anyway - I'll add the pervasive support tonight after work, ok?
Fantastic, Thanks a lot!
Please try...
Works fantastic, great thanks !
cool :)
--
Torsten
On ro, mar 05, 2003 at 06:14:39 +0100, Torsten Curdt wrote:
snip/
Anyway - I'll add the pervasive support tonight after work, ok?
Fantastic, Thanks a lot!
Please try...
Works fantastic, great thanks !
ouzo
--
__
| / \ |Leszek Gawron// \\
Leszek Gawron wrote:
On ro, mar 05, 2003 at 01:16:26 +0100, Torsten Curdt wrote:
So you think cocoon should fix all the bugs that software vendor X
refuses to fix? come on!
I have the pervasive case in my mind and was reffering to that. I think it's
not even a bug (that awful performance) but the
On 05.Mar.2003 -- 09:43 AM, Torsten Curdt wrote:
Leszek Gawron wrote:
On ??ro, mar 05, 2003 at 01:16:26 +0100, Torsten Curdt wrote:
So you think cocoon should fix all the bugs that software vendor X
refuses to fix? come on!
I have the pervasive case in my mind and was reffering to that. I
On ro, mar 05, 2003 at 01:16:26 +0100, Torsten Curdt wrote:
Anyway, Leszek, could you please check with the same ResultSet type
(ResultSet.TYPE_SCROLL_INSENSITIVE,ResultSet.CONCUR_READ_ONLY)
as in the JdbcEsqlQuery?
Sure no problem, gonna make this my first thing to do in the morning
snip/
You're joking. At least in book, full featured would entail providing
a SQL parser and talking to the server native protocol. Certainly not
as part of Cocoon.
Well, I did not mean it *that* full featured way ;)
Though it might be worth to have a look into all that is available...
I thought
got tired of waiting to finish so it will take at least 5 minutes (last time it took 9.9 minutes)
Could you try the PreparedStatment testcase without
TYPE_SCROLL_INSENSITIVE, CONCUR_READ_ONLY and the Statement testcase
with, please?
Thanks
--
Torsten
On ro, mar 05, 2003 at 11:52:42 +0100, Torsten Curdt wrote:
got tired of waiting to finish so it will take at least 5 minutes (last
time it took 9.9 minutes)
cannot really tell how much it took - poor wget timed out
Could you try the PreparedStatment testcase without
Leszek Gawron wrote:
On ro, mar 05, 2003 at 11:52:42 +0100, Torsten Curdt wrote:
got tired of waiting to finish so it will take at least 5 minutes (last
time it took 9.9 minutes)
cannot really tell how much it took - poor wget timed out
Could you try the PreparedStatment testcase without
On ro, mar 05, 2003 at 12:45:53 +0100, Torsten Curdt wrote:
...then we can just easily add support for pervasive and you should be
fine. So we need to create the PervasiveEsqlQuery class and register it
in the EsqlConnection class. Does pervasive support any kind of
ResultSet limiting (like
Leszek Gawron wrote:
On ro, mar 05, 2003 at 12:45:53 +0100, Torsten Curdt wrote:
...then we can just easily add support for pervasive and you should be
fine. So we need to create the PervasiveEsqlQuery class and register it
in the EsqlConnection class. Does pervasive support any kind of
On ro, mar 05, 2003 at 01:04:41 +0100, Torsten Curdt wrote:
Leszek Gawron wrote:
On ro, mar 05, 2003 at 12:45:53 +0100, Torsten Curdt wrote:
...then we can just easily add support for pervasive and you should be
fine. So we need to create the PervasiveEsqlQuery class and register it
in
On Wednesday, March 5, 2003, at 06:52 AM, Leszek Gawron wrote:
On ro, mar 05, 2003 at 12:45:53 +0100, Torsten Curdt wrote:
...then we can just easily add support for pervasive and you should be
fine. So we need to create the PervasiveEsqlQuery class and register
it
in the EsqlConnection class.
snip/
Anyway - I'll add the pervasive support tonight after work, ok?
Fantastic, Thanks a lot!
Please try...
--
Torsten
On wto, mar 04, 2003 at 04:25:09 +0100, Christian Haul wrote:
On 04.Mar.2003 -- 04:08 PM, Leszek Gawron wrote:
2. Same query run by cocoon:
INFO(2003-03-04) 16:03.13:573 [access]
(/romes/data-old/contractors-offline-bug) Thread-6/CocoonServlet:
while trying to test the esql:get-object I have run just this:
esql:execute-query
esql:query
SELECT * from kontrah/esql:query
esql:results
esql:row-resultsa/a/esql:row-results
/esql:results
/esql:execute-query
The
On wto, mar 04, 2003 at 05:05:37 +0100, Torsten Curdt wrote:
while trying to test the esql:get-object I have run just this:
esql:execute-query
esql:query
SELECT * from kontrah/esql:query
esql:results
esql:row-resultsa/a/esql:row-results
On Tuesday, March 4, 2003, at 11:11 AM, Leszek Gawron wrote:
Yes but some people in this discussion blamed the amount of SAX events
to
handle for bad performance. So now it is clear that it's the rowset
traversal
that consumes so much CPU, but still why? I'm not skilled in JDBC. The
only
On 04.Mar.2003 -- 05:11 PM, Leszek Gawron wrote:
On wto, mar 04, 2003 at 05:05:37 +0100, Torsten Curdt wrote:
while trying to test the esql:get-object I have run just this:
esql:execute-query
esql:query
SELECT * from kontrah/esql:query
esql:results
Not weird at all!
You are still looping through the ResultSet (row-results)
Yes but some people in this discussion blamed the amount of SAX events to
handle for bad performance. So now it is clear that it's the rowset traversal
that consumes so much CPU, but still why?
Well, because the traversal
On wto, mar 04, 2003 at 05:26:01 +0100, Christian Haul wrote:
On 04.Mar.2003 -- 05:11 PM, Leszek Gawron wrote:
On wto, mar 04, 2003 at 05:05:37 +0100, Torsten Curdt wrote:
while trying to test the esql:get-object I have run just this:
esql:execute-query
esql:query
SELECT *
On 04.Mar.2003 -- 05:44 PM, Leszek Gawron wrote:
On wto, mar 04, 2003 at 05:26:01 +0100, Christian Haul wrote:
If you have a esql:parameter .../ in your query, esql uses a
prepared statement. Otherwise it won't.
Strange: even though my query does not contain esql:parameter tags what I see
On 04.Mar.2003 -- 05:44 PM, Leszek Gawron wrote:
On wto, mar 04, 2003 at 05:26:01 +0100, Christian Haul wrote:
If you have a esql:parameter .../ in your query, esql uses a
prepared statement. Otherwise it won't.
Strange: even though my query does not contain esql:parameter tags what I
On wto, mar 04, 2003 at 05:39:01 +0100, Torsten Curdt wrote:
Not weird at all!
You are still looping through the ResultSet (row-results)
Yes but some people in this discussion blamed the amount of SAX events to
handle for bad performance. So now it is clear that it's the rowset
traversal
Ooops. Torsten, I believe this changed with your refactoring, right?
(2.0.5 still uses plain statements in this case) Any idea why you have
changed this? (OK, PreparedStatements do have advantages, but)
Yes, I did. IIRC it lead to a much easier handling inside the classes.
And due to the reported
On wto, mar 04, 2003 at 07:27:28 +0100, Torsten Curdt wrote:
Ooops. Torsten, I believe this changed with your refactoring, right?
(2.0.5 still uses plain statements in this case) Any idea why you have
changed this? (OK, PreparedStatements do have advantages, but)
Yes, I did. IIRC it lead to
it's faster. So whom shall we kick in the but? Database A user or
database B user? Of course we could make it... configurable *ring* *ring*
maybe just esql:query and esql:prepared query?
It's not the logicsheet.but the helper classes that create the
problem. Of course it is doable - the
On ro, mar 05, 2003 at 01:16:26 +0100, Torsten Curdt wrote:
So you think cocoon should fix all the bugs that software vendor X
refuses to fix? come on!
I have the pervasive case in my mind and was reffering to that. I think it's
not even a bug (that awful performance) but the way they have
28 matches
Mail list logo
