continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Venisse <emman...@venisse.net>
Subject Re: introduction
Date Wed, 12 Jul 2006 15:53:47 GMT
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 <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