Stephen Ince wrote:
> FYI.
> I was able to get my app working with castor/postgres and derby. I am
> using castor 1.01. It seems to be a lot faster than the current release.
>
> FIXES and work arounds.
> 1) Changed to using IDENTITY key generator from HIGH/LOW. Over a period
> of time (week) the high/low seems to get out of sync.
>
> 2) ReadOnly transaction issue. This is not really a castor issue but
> apache/db connection pooling issue. It is not resetting the connections.
> Work around.
>
> reset jdbc connection in
> org.castor.persist.LocalTransactionContext.createConnection()
Hmm, trying to get my head around this .. ;-). I guess you are saying
that - once a connection is being re-used - it will have a wrong state
associated upon retrieval from the connection pool, correct ? Ideally,
it would be nice if such code could be added to
Database.close()/TransactionContext.close(), but that would imply that
we woul dhave to force folks to close a Database instance (rather than
waiting for it to be 'auto-closed'.
> conn.setReadOnly(false)
>
> 3) Derby identity generator bug.
> In
> org.exolab.castor.jdo.keygen.IdentityKeyGenerator
>
> public void supportsSqlType( int sqlType )
> throws MappingException
> {
> if (sqlType != Types.INTEGER &&
> sqlType != Types.NUMERIC &&
> sqlType != Types.DECIMAL &&
> sqlType != Types.BIGINT) {
> throw new MappingException(
> Messages.format("mapping.keyGenSQLType",
> getClass().getName(), new Integer(sqlType)));
> }
>
> if (sqlType != Types.INTEGER &&
> fName.equals("hsql")) {
> throw new MappingException(
> Messages.format("mapping.keyGenSQLType",
> getClass().getName(), new Integer(sqlType)));
> }
>
> // ODS: fix
> if (sqlType == Types.NUMERIC &&
> fName.equals("derby")) {
> throw new MappingException(
> Messages.format("mapping.keyGenSQLType",
> getClass().getName(), new Integer(sqlType)));
> }
> }
>
> Steve
> ----- Original Message ----- From: "Stephen Ince" <[EMAIL PROTECTED]>
> To: <[email protected]>
> Sent: Wednesday, January 30, 2008 1:19 PM
> Subject: Re: [castor-user] read-only connection for generating keys for
> postgres.
>
>
>> Werner,
>> I am having a hard time reproducing "read-only transaction" case
>> outside of my webapp. I am also getting the read-only error for
>> MAX-KEY key generation. Any suggestions on how I can reproduce it. I
>> am thinking about spawning a few threads and do not close the jdo
>> sessions. Sofar the single threaded case is not reproducible.
>>
>> Here is a the stack trace for the webapp.
>>
>>
>> a.. This Database operation failed: : SQL exception in the key
>> generator org.exolab.castor.jdo.keygen.MaxKeyGenerator:
>> org.postgresql.util.PSQLException: ERROR: transaction is read-only.:
>> ERROR: transaction is read-only
>>
>>
>> Caused by: org.postgresql.util.PSQLException: ERROR: transaction is
>> read-only
>> at
>> org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryEx
>> ecutorImpl.java:1548)
>> at
>> org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutor
>> Impl.java:1316)
>> at
>> org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.ja
>> va:191)
>> at
>> org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Stat
>> ement.java:452)
>> at
>> org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(Abstract
>> Jdbc2Statement.java:351)
>> at
>> org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery(AbstractJdbc
>> 2Statement.java:255)
>> at
>> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(Dele
>> gatingPreparedStatement.java:92)
>> at
>> org.exolab.castor.jdo.keygen.MaxKeyGenerator.generateKey(MaxKeyGenera
>> tor.java:162)
>> at
>> org.exolab.castor.jdo.engine.SQLStatementCreate.generateKey(SQLStatem
>> entCreate.java:384)
>> at
>> org.exolab.castor.jdo.engine.SQLStatementCreate.executeStatement(SQLS
>> tatementCreate.java:189)
>> at
>> org.exolab.castor.jdo.engine.SQLEngine.create(SQLEngine.java:313)
>> at
>> org.exolab.castor.persist.ClassMolder.create(ClassMolder.java:694)
>> at
>> org.exolab.castor.persist.LockEngine.create(LockEngine.java:532)
>> at
>> org.castor.persist.AbstractTransactionContext.walkObjectsToBeCreated(
>> AbstractTransactionContext.java:817)
>> at
>> org.castor.persist.AbstractTransactionContext.create(AbstractTransact
>> ionContext.java:777)
>> at
>> org.exolab.castor.jdo.engine.AbstractDatabaseImpl.create(AbstractData
>> baseImpl.java:302)
>>
>>
>> Steve
>> ----- Original Message ----- From: "Werner Guttmann"
>> <[EMAIL PROTECTED]>
>> To: <[email protected]>
>> Sent: Friday, January 25, 2008 6:22 PM
>> Subject: Re: [castor-user] read-only connection for generating keys
>> for postgres.
>>
>>
>>> I think I'll need a full test case so that I am able to run it
>>> against e.g. Derby. Can you please supply us with one ?
>>>
>>> Werner
>>>
>>> Stephen Ince wrote:
>>>> Werner,
>>>> The read-only connection error showed up again on postgres. So
>>>> "<param name="same-connection" value="false"/>" didn't resolve the
>>>> problem. This problem only occurs with postgresql and derby.
>>>> Hsqldb, db2, oracle and sqlserver all work fine. I think it has
>>>> something to do with getting a connection from a pool that was
>>>> previously set to read-only.
>>>>
>>>> Steve
>>>>
>>>> A fatal error occurred while creating/updating
>>>> com.opendemand.security.UserProfi
>>>> le using SQL: UPDATE "users" SET
>>>> "user_name"=?,"title"=?,"fname"=?,"minitial"=?,
>>>> "lname"=?,"passwd"=?,"role"=?,"status"=?,"license"=?,"total_test_ran"=?,"test_ti
>>>> me"=?,"last_login_time"=?,"test_time_elapsed"=?,"group_id"=?,"company"=?,"accept
>>>> _license"=?,"email"=?,"url"=?,"referred_by"=?,"telephone"=?,"fax"=?,"address"=?,
>>>> "city"=?,"state"=?,"zipcode"=?,"country"=? WHERE "user_id"=?
>>>> org.postgresql.util.PSQLException: ERROR: transaction is read-only
>>>> at
>>>> org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryEx
>>>> ecutorImpl.java:1548)
>>>> at
>>>> org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutor
>>>> Impl.java:1316)
>>>> at
>>>> org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.ja
>>>>
>>>> Steve
>>>> ----- Original Message ----- From: "Werner Guttmann"
>>>> <[EMAIL PROTECTED]>
>>>> To: <[email protected]>
>>>> Sent: Friday, January 25, 2008 4:30 PM
>>>> Subject: Re: [castor-user] read-only connection for generating keys
>>>> for postgres.
>>>>
>>>>
>>>>> Interesting, indeed. How did you come about this solution for
>>>>> postgreSQL, if I may ask ?
>>>>>
>>>>> Werner
>>>>>
>>>>> Stephen Ince wrote:
>>>>>> Werner,
>>>>>> I think I solved the problem for postgres but not derby.
>>>>>> <mapping>
>>>>>> <key-generator name="HIGH-LOW" alias="keygen">
>>>>>> :
>>>>>> <param name="same-connection" value="false"/>
>>>>>> </key-generator>
>>>>>> </mapping>
>>>>>> This seemed to worked for postgres. With derby I get a similiar
>>>>>> error.
>>>>>> Nested error: java.sql.SQLException: An SQL data change is not
>>>>>> permitted for a read-only connection, user or database.: An SQL
>>>>>> data change is not permitted for a read-only connection, user or
>>>>>> database.
>>>>>> Steve
>>>>>> ----- Original Message -----
>>>>>> From: "Werner Guttmann" <[EMAIL PROTECTED]
>>>>>> <mailto:[EMAIL PROTECTED]>>
>>>>>> To: <[email protected] <mailto:[email protected]>>
>>>>>> Sent: Friday, January 25, 2008 3:48 PM
>>>>>> Subject: Re: [castor-user] read-only connection for generating
>>>>>> keys for postgres.
>>>>>>
>>>>>> > Stephen,
>>>>>> >
>>>>>> > can you supply me with a test case (packaged as part of a Jira
>>>>>> issue) so
>>>>>> > that I could easily replay this problem ?
>>>>>> >
>>>>>> > Regards
>>>>>> > Werner
>>>>>> >
>>>>>> > Stephen Ince wrote:
>>>>>> >> I am getting the following error when I try to save an object
>>>>>> using a
>>>>>> >> key sequence.
>>>>>> >> This works fine for oracle, sqlserver, hsqldb and db2.
>>>>>> >>
>>>>>> >> Here is my database.xml. Is there something I can do it to
>>>>>> force castor
>>>>>> >> to use a different connection to get the keys or change
>>>>>> connection from
>>>>>> >> read-only to non read-only?
>>>>>> >>
>>>>>> >> org.exolab.castor.jdo.keygen.MaxKeyGenerator:
>>>>>> >> org.postgresql.util.PSQLException: ERROR: transaction is
>>>>>> read-only.:
>>>>>> >> ERROR: transaction is read-only
>>>>>> >>
>>>>>> >> <!DOCTYPE mapping PUBLIC "-//EXOLAB/Castor Mapping DTD Version
>>>>>> 1.0//EN"
>>>>>> >> "http://castor.exolab.org/mapping.dtd";>
>>>>>> >> <mapping>
>>>>>> >> <key-generator name="HIGH-LOW" alias="keygen">
>>>>>> >> <param name="table" value="seq"/>
>>>>>> >> <param name="key-column" value="seq_table_name"/>
>>>>>> >> <param name="value-column" value="max_pk_value"/>
>>>>>> >> <param name="grab-size" value="50"/>
>>>>>> >> <param name="same-connection" value="true"/>
>>>>>> >> </key-generator>
>>>>>> >> </mapping>
>>>>>> >>
>>>>>> >> Steve
>>>>>> >>
>>>>>> >>
>>>>>> ---------------------------------------------------------------------
>>>>>> >> To unsubscribe from this list please visit:
>>>>>> >>
>>>>>> >> http://xircles.codehaus.org/manage_email
>>>>>> >>
>>>>>> >>
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> ---------------------------------------------------------------------
>>>>>> > To unsubscribe from this list please visit:
>>>>>> >
>>>>>> > http://xircles.codehaus.org/manage_email
>>>>>> >
>>>>>> >
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe from this list please visit:
>>>>>
>>>>> http://xircles.codehaus.org/manage_email
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list please visit:
>>>>
>>>> http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list please visit:
>>>
>>> http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
