continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Bengtson <e...@jpox.org>
Subject Re: introduction
Date Sat, 08 Jul 2006 19:42:50 GMT
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.

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.

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.

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.

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.

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.



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.

> 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

> 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 <emmanuel@venisse.net>:

> 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
> >
> >
> >
>
>




Mime
View raw message