Thanks for your answers.
Comments inline
Erik Bengtson a écrit :
Salut,
Some issues from user list
issue 1:
Re: ERROR 22001: A truncation error was encountered trying to shrink VARCHAR
'javax.jdo.JDODataStoreException
<solution>
The data you are storing is probably larger than the column size. You should
consider changing the BUILDRESULT.ERROR column to BLOB or truncating the error
text before storing.
ok, we'll try it.
issue 2:
Using continuum with Sybase SQLServer
Emmanuel says: "So it's a jpox bug."
<solution>
I'm not able to understand the issue, however I noticed that you create the
tables during the first transaction. You should instead have an init process
that invokes the JPOX schematool in order to do that, for the only reason that
some databases does not allow creating tables and quering or inserting in the
same transaction.
Secondly, to improve performance the PMF that runs your transactions should have
validation and creation of schema disabled. This is very critical for
performance.
it will improve performance at startup only, right?
issue 3:
How do i intergrate Continuum with mysql database ?
<solution>
Error happening during validation of schema due to the buggy mysql jdbc driver.
(oracle and mysql have very poor jdbc drivers. mysql has very often lots of
regressions)
To avoid these issues, again the solution is to disable validation of schema.
ok.
issue 4:
[vote] Release Continuum 1.0.3
"Wrong precision for column CHANGEFILE.MODEL_ENCODING : was
255 (according to the JDBC dr
iver) but should be 256 (based on the MetaData definition). "
<solution>
Sadly, JDO 2 final has changed the default length from 255 to 256. JPOX default
used to be 255 and in newer versions it is 256. JPOX allows changing this
default in a PMF setting. See docs.
I know it. we use 255 so old database are always compatible with the new schema.
If we change some fields to blob for issue 1, we'll need a migration tool for
the new schema.
Issue 5:
Continuum 1.0.3 RC require some tester
For the memory leak, it seems it's a problem with jpox rc1.
<solution>
JPOX has corrected issues on memory handling in latest versions. JPOX no longer
has such problems.
Continuum too :-)
Issue 6:
3984 [WrapperSimpleAppMain] ERROR JPOX.RDBMS.SCHEMA - An exception was thrown
while adding/validating class(es) : The size (8192) given to the column
'COMMENT' exceeds the maximum allowed for any data type (8000).
java.sql.SQLException: The size (8192) given to the column 'COMMENT' exceeds the
maximum allowed for any data type (8000).
<solution>
Some databases limits the "row" length or have data types limits.
To solve it change this column to BLOB.
Issue 7:
Foreign Keys violation and locking issues.
<solution>
Locking issues is usually due to concurrency and isolation levels. This is
something you have to handle in the application and configure the isolation
levels it fits better for your app. I dont believe you have any issue in derby
or jpox. If you increase isolation levels, you probably have more contention,
but less dead locks.
On foreign keys, this is usually a problem in the application for not
adding/removing dependencies first.
We don't add/remove dependencies first, it's done in cascade. It works well but in some case (hard
to reproduce) we have foreign Keys violation and locking issues.
I strongly recommend during QA testing to use a good RDBMS that enforces
constraints, like derby, oracle, db2 or mssql. Mysql is not a good choice in
this case.
For our tests, we use hsqldb because the database is created quickly. And we use derby for
production and integration tests
An other pb is at the continuum startup, we update the state of all projects
and store it in
database, all the code is ok but when we look in database state isn't
updated. The same code is used
in an other part and it works fine.
if you have more info, I may be able to help
http://svn.apache.org/viewvc/maven/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/DefaultContinuum.java?view=markup
at line 1968, state is always equals to p.getState(), so it's wrong. jpox doesn't update the
database there
Don't hesitate if you need more informations and if you want to look at our
code.
I would love to but my time is short, however if you have design documents, I
can do a review.
Quoting Emmanuel Venisse <[EMAIL PROTECTED]>:
Thanks Erik.
In Continuum, we use jpox with derby. Lot of users get some exception with
them on requests that
failed like foreign key violation, insert/delete errors, deadlock errors...
Our problem is this errors doesn't appears all the time and it's very
difficult to reproduce them.
I'm not sure (but I think) errors are in jpox and not in derby. I know
deadlock lock and timeout
lock are fixed in the new derby version and we'll update it.
You can see some errors in users list:
http://www.nabble.com/forum/Search.jtp?forum=13868&local=y&query=jpox
and some issue in our jira:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&mode=hide&pid=10540&sorter/order=DESC&sorter/field=priority&resolution=-1&component=12224
An other pb is at the continuum startup, we update the state of all projects
and store it in
database, all the code is ok but when we look in database state isn't
updated. The same code is used
in an other part and it works fine.
Don't hesitate if you need more informations and if you want to look at our
code.
Emmanuel
Erik Bengtson a écrit :
Hi All,
I'm a JPOX developer and because Continuum uses JPOX I thought it may be a
good
idea to keep an eye in this list to help you guys in sorting out issues
with
the product.
As outcome of following this project, I'm willing to reduce the
troubleshooting
time spent when using JPOX and thus improve JPOX operating tools, like
documentation, logging, clear error messages and so on.
Regards,
Erik Bengtson
