Hi Johan -
I will be able to look into this error more later today but wanted to
get this observation to you ASAP since this issue seems to have set for
a week. The root cause of the failure is this exception taken from one
of the repeated stack traces from the MCWrapper class:
original
Hi Mag,
This issue (bug 472) is certainly on my wishlist but since it's a modest
sized feature, it won't get into the October release. We need someone to
work on this feature and no-one has been donated to this effort yet.
You're welcome to help out!
Cheers,
-Rick
Mag Gam wrote:
I would
FYI. I think it underscores that those of us building web-tier apps need
to be very conscious of security during design, implementation and
deployment. It's no longer core IT that is threatened.
http://www.geekzone.co.nz/content.asp?contentid=5222
begin:vcard
fn:David W Van Couvering
n:Van
As craig points out it is important in performance testing to say
exactly what you are measuring. In general Derby will try to
stream rows to the user before it has finished looking at all rows.
So often looking at the first row will and stopping will mean that
many rows have not been processed.
Another little detail about optimization is that Statement.setMaxRows() kind of functions on the JDBC side may not be sufficientsince it iscalled after SQL statement is prepared and returned as an object (after query plan is built). Therefore, it may be necessary to have language syntax to
Daniel John Debrunner wrote:
Andreas Fredriksson wrote:
On Thu, 2005-09-15 at 09:59 +0200, Knut Anders Hatlen wrote:
Your patch is against Derby 10.1.1.0, but I see that the development
sources have changed since that version. Some of the changes are
similar to those you proposed. Could
Hi Stanley
Thank you for responding.
I don't know how to do what you ask, though. By the nature of the message
driven bean in which context the code runs I do not and should not know
about any open transactions. The container starts the transaction, Hibernate
senses it is running inside a
