Re: Problem w/ SequenceManagerTransientImpl in 1.0.4

Hi Ailish,

all comments based on latest version from SVN OJB_1_0_RELEASE branch. If 
possible please test the upcoming version (read carefully the 
release-notes before use ;-)).
To get the sources use a SVN-client with:
http://svn.apache.org/repos/asf/db/ojb/branches/OJB_1_0_RELEASE


Byrne, Ailish M wrote:
> Hello,
> 
> We encountered a problem with the SequenceManagerTransientImpl.  We have
> two objects that are related; bank account has a bank on it.  A key to
> the bank account table has a custom FieldConversion implementation for
> encryption/decryption associated with it.  When we refresh the
> references on a new bank account, OJB goes to retrieve the bank and uses
> SequenceManagerTransientImpl to initialize any null keys on bank account
> with a unique value.  However, after SequenceManagerTransientImpl
> returns a long > 1000, AbstractSequenceManager calls the sqlToJava
> method on the custom FieldConversion (in the getUniqueLong method).  The
> custom FieldConversion bombs, because it's being asked to unencrypt and
> already unencrypted value.  So, we overrode getUniqueValue in
> SequenceManagerTransientImpl as follows...
>     public Object getUniqueValue(FieldDescriptor field) throws
> SequenceManagerException
>     {
>         return field.getJdbcType().sequenceKeyConversion(new
> Long(getUniqueLong(field)));
>         // perform a sql to java conversion here, so that clients do
>         // not see any db specific values
>         // abyrne commented out: result =
> field.getFieldConversion().sqlToJava(result);
>         // abyrne commented out: return result;
>     }
> We would appreciate your feedback on whether or not this seems
> problematic.  

The conversion is already done in the super-class
http://svn.apache.org/viewvc/db/ojb/branches/OJB_1_0_RELEASE/src/java/org/apache/ojb/broker/util/sequence/AbstractSequenceManager.java?view=markup
See method #getUniqueValue(...)
This method is called by OJB to lookup the next key.


> Also, we have been trying to be diligent about reporting
> issues to you and hope that we can get back on a standard OJB version
> soon.
> 
> FYI, other issues that we have fixed in our custom 1.0.4 build and
> reported to you are...

I have fixed all issues (see below), so OJB 1.0.5 should run without 
patches. But upcoming 1.0.5 is more then a maintenance-release. Some new 
methods added to the PB-api and a few internal interfaces are modified.
http://svn.apache.org/viewvc/db/ojb/branches/OJB_1_0_RELEASE/release-notes.txt?view=markup


> - "Out of the box OJB only supports CLOBs on DBCP, P6Spy, JBoss, or
> vanilla JDBC connections. I had to modify their code to allow it to
> unwrap PreparedStatements from XAPool prepared statements (which is the
> library Workflow uses for JTA and XA)."

XAPool is now supported. The unwrap stuff is now separated in class
http://svn.apache.org/viewvc/db/ojb/branches/OJB_1_0_RELEASE/src/java/org/apache/ojb/broker/util/UnwrapHelper.java?view=markup
also it's possible to add additional unwarp pattern at runtime.


> - "MySQLPlatformImpl did not have support for the
> StoredProcedureSequenceManagerImpl.  This is fixed in OJB 1.0.5."

Add section about mysql here
http://svn.apache.org/viewvc/db/ojb/branches/OJB_1_0_RELEASE/src/doc/forrest/src/documentation/content/xdocs/docu/guides/sequencemanager.xml?view=markup


> 
> Also, we recently tried to use the StoredProcedureSequenceManagerImpl
> with Oracle, because we were working on MySQL compatibility for our app
> and wanted to use the same sequence manager for both.  We failed because
> of invalid sql generated by
> PlatformOracle9i.prepareNextValProcedureStatement.

Please report this bug to JIRA (if possible with stack trace)
http://issues.apache.org/jira/browse/OJB

regards,
Armin


   Rather than fixing
> this one, we opted to just keep using the SequenceManagerNextValImpl for
> now.
> 
> Thanks,
> Ailish
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 
>