You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by "Gentry, Michael (Contractor)" <mi...@fanniemae.com> on 2006/06/29 23:27:56 UTC
Sybase adapter changes?
I have an application running fine "in production" using Cayenne 1.2M9,
but when testing it locally with Cayenne 1.2 RC1, I get this exception:
Exception = com.sybase.jdbc2.jdbc.SybSQLException: Stored procedure
'getpid' may be run only in unchained transaction mode. The 'SET CHAINED
OFF' command will cause the current session to use unchained transaction
mode.
I didn't make any changes to the Cayenne portion, just twiddled a few
Tapestry bits and was testing the application out. The error occurs
when I insert a record and need a primary key -- I call a stored
procedure directly using JDBC in my custom PK class (which has been
working perfectly for over a year):
public Object generatePkForDbEntity(DataNode dataNode, DbEntity ent)
throws Exception
{
// Get our connection so we can call the stored procedure
Connection connection =
dataNode.getDataSource().getConnection();
CallableStatement getPID = connection.prepareCall("{call
getpid(?,?,?)}");
// Prepare the stored procedure
getPID.setInt(1, currentBlockSize); // Slot 1: Number of
PIDs requested
getPID.registerOutParameter(2, Types.BINARY); // Slot 2: First PID
allocated
getPID.registerOutParameter(3, Types.INTEGER); // Slot 3: Number of
PIDs allocated
try
{
// Call the stored procedure
getPID.execute();
...
I get the exception on the execute() line.
I did diffs on the Sybase code, but didn't see any changes -- at least
not since it was converted to Subversion.
Anyone have ideas?
Thanks!
/dev/mrg
PS. Auto commit is false.
Re: Sybase adapter changes?
Posted by Andrus Adamchik <an...@objectstyle.org>.
Mike,
I just committed a simpler fix:
http://issues.apache.org/cayenne/browse/CAY-588
With this patch all tests pass successfully.
> Installing Panther on your old PB. Man, I knew I was a pain in the
> behind.
Wasn't that bad after all. The worse piece is always Sybase - it
takes some time to remember how to dump a transaction log and all
that nonsense.
Andrus
On Jul 6, 2006, at 6:16 PM, Michael Gentry wrote:
> Installing Panther on your old PB. Man, I knew I was a pain in the
> behind.
>
> What would be the rationale for caching the DataSource (a PoolManager
> for my setup -- if using JNDI, would this be different?) and not a
> JDBC Connection?
>
> Thanks,
>
> /dev/mrg
>
>
> On 7/6/06, Andrus Adamchik <an...@objectstyle.org> wrote:
>> If you want to go that way, I suggest caching a DataSource, not
>> Connection.
>>
>> BTW, I am in the process of installing Panther on my old laptop to
>> give Sybase installation another try.
>>
>> Andrus
>>
>> On Jul 6, 2006, at 2:02 PM, Gentry, Michael ((Contractor)) wrote:
>>
>> > I have a feeling I know the answer to this already ... Would
>> > dataNode.getDataSource() always return a PoolManager object? (I'm
>> > guessing no.)
>> >
>> > I was thinking of maybe getting the username/password/jdbc:/etc
>> > from it
>> > and opening (and caching) a PK connection. Seems a bit
>> inefficient,
>> > though, holding a connection only for PK generation. I suspect
>> this
>> > isn't really what you had in mind, though ...
>> >
>> > /dev/mrg
>> >
>> >
>> > -----Original Message-----
>> > From: Andrus Adamchik [mailto:andrus@objectstyle.org]
>> > Sent: Monday, July 03, 2006 9:33 PM
>> > To: cayenne-dev@incubator.apache.org
>> > Subject: Re: Sybase adapter changes?
>> >
>> >
>> > Ok, another failed attempt installing Sybase (this time on Mac - it
>> > sort of installs on Tiger, but the preferences pane is broken...
>> > someday I'll figure out a manual startup procedure).
>> >
>> >> Did the old code get the PKs before starting the main
>> >> commitChanges() transaction?
>> >
>> > Yes it did, resulting in inconsistency between Cayenne-managed
>> > transactions and container transactions.
>> >
>> >> I was thinking it might be starting a new transaction before
>> >> calling the PK generator ...
>> >
>> > I am thinking along the same lines. To make it clean, such
>> > transaction has to run in a thread separate from the user
>> transaction
>> > thread. A PkGenerator may keep an idle "PK thread" that waits
>> until a
>> > request from a user thread comes in for a PK and the local cache is
>> > exhausted. When this happens, the PK thread awakes, obtains a
>> > connection (outside of the user transaction, effectively
>> starting its
>> > own parallel transaction), fills PK cache with new range of values,
>> > notifies the user thread, and goes back to the idle state.
>> >
>> > This shouldn't add too much overhead (and such overhead can be
>> > reduced by increasing the PK cache size), still I would say we make
>> > this behavior an optional setting that can be tweaked on
>> > JdbcPkGenerator.
>> >
>> > I'd say we add it to 3.0 (we have a separate branch for high
>> priority
>> > issues that can't be included in 1.2).
>> >
>> > Andrus
>> >
>> >
>> > On Jun 30, 2006, at 3:05 PM, Gentry, Michael ((Contractor)) wrote:
>> >> I was thinking it might be starting a new transaction before
>> >> calling the
>> >> PK generator ... Did the old code get the PKs before starting the
>> >> main
>> >> commitChanges() transaction?
>> >>
>> >> I actually wasn't managing the auto-commit manually. I was just
>> >> using
>> >> the connection and it was working, prior to M12. I didn't know
>> the
>> >> auto-commit value prior to the problem. :-)
>> >>
>> >> The last part of your message sounds a bit frightening ...
>> >>
>> >> I just looked at the current Sybase PK generator and it grabs the
>> >> connection, just like I'm doing, and calls the auto_pk_for_table
>> >> stored
>> >> procedure. Isn't there a chance that generator could fail now,
>> >> too? I
>> >> think there is a way when creating the SP to tell Sybase to
>> make it
>> >> unchained, but the current code doesn't specify that. (I'd
>> have to
>> >> Google search again to find the right SQL.)
>> >>
>> >> Thanks,
>> >>
>> >> /dev/mrg
>> >>
>> >> PS. Changing the chaining mode of the SP might not be possible for
>> >> us.
>> >>
>> >>
>> >> -----Original Message-----
>> >> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
>> >> Sent: Friday, June 30, 2006 12:58 PM
>> >> To: cayenne-dev@incubator.apache.org
>> >> Subject: Re: Sybase adapter changes?
>> >>
>> >>
>> >> Ok, I see. The new code wraps PK generator in the main
>> transaction,
>> >> so I can see how managing auto-commit property manually in your
>> >> custom generator can get you in trouble. One possible
>> workaround may
>> >> be using a separate connection ... which DataNode makes really
>> hard
>> >> by returning a wrapper inner class when in transaction. So you may
>> >> need to unbind the transaction from the thread, call
>> >> DataNode.getDataSource(), then rebind transaction back.
>> >>
>> >> Andrus
>> >>
>> >>
>> >> On Jun 30, 2006, at 3:38 PM, Gentry, Michael ((Contractor)) wrote:
>> >>
>> >>> Judging by the release notes at:
>> >>>
>> >>> http://www.objectstyle.org/confluence/display/CAY/2006/03/23/
>> Cayenne
>> >>> +ORM
>> >>> +1.2M12+Release
>> >>>
>> >>> I'd guess the nested DataContexts are a likely place to look?
>> >>>
>> >>> Of course, that brings up the question: is this a bug that
>> should be
>> >>> fixed or should I just update my PK generator to store the auto-
>> >>> commit
>> >>> flag, set it true for my usage, then set it back to the original
>> >>> value?
>> >>> Also, do you think this would effect running stored procedures
>> >>> through
>> >>> Cayenne instead of JDBC directly, too?
>> >>>
>> >>> Thanks,
>> >>>
>> >>> /dev/mrg
>> >>>
>> >>>
>> >>> -----Original Message-----
>> >>> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
>> >>> Sent: Friday, June 30, 2006 10:33 AM
>> >>> To: cayenne-dev@incubator.apache.org
>> >>> Subject: Re: Sybase adapter changes?
>> >>>
>> >>>
>> >>> IIRC transaction API changes also happened around M12.
>> >>>
>> >>> Andrus
>> >>>
>> >>> On Jun 30, 2006, at 3:19 PM, Gentry, Michael ((Contractor))
>> wrote:
>> >>>
>> >>>> M9: Pass (auto-commit = true)
>> >>>> M10: Pass (auto-commit = true)
>> >>>> M11: Pass (auto-commit = true)
>> >>>> M12: Fail (auto-commit = false)
>> >>>> RC1: Fail (auto-commit = false)
>> >>>>
>> >>>> Well, at least that provides a good starting point. :-)
>> >>>>
>> >>>> /dev/mrg
>> >>>>
>> >>
>> >>
>> >
>> >
>>
>>
>
Re: Re: Sybase adapter changes?
Posted by Michael Gentry <bl...@gmail.com>.
Installing Panther on your old PB. Man, I knew I was a pain in the behind.
What would be the rationale for caching the DataSource (a PoolManager
for my setup -- if using JNDI, would this be different?) and not a
JDBC Connection?
Thanks,
/dev/mrg
On 7/6/06, Andrus Adamchik <an...@objectstyle.org> wrote:
> If you want to go that way, I suggest caching a DataSource, not
> Connection.
>
> BTW, I am in the process of installing Panther on my old laptop to
> give Sybase installation another try.
>
> Andrus
>
> On Jul 6, 2006, at 2:02 PM, Gentry, Michael ((Contractor)) wrote:
>
> > I have a feeling I know the answer to this already ... Would
> > dataNode.getDataSource() always return a PoolManager object? (I'm
> > guessing no.)
> >
> > I was thinking of maybe getting the username/password/jdbc:/etc
> > from it
> > and opening (and caching) a PK connection. Seems a bit inefficient,
> > though, holding a connection only for PK generation. I suspect this
> > isn't really what you had in mind, though ...
> >
> > /dev/mrg
> >
> >
> > -----Original Message-----
> > From: Andrus Adamchik [mailto:andrus@objectstyle.org]
> > Sent: Monday, July 03, 2006 9:33 PM
> > To: cayenne-dev@incubator.apache.org
> > Subject: Re: Sybase adapter changes?
> >
> >
> > Ok, another failed attempt installing Sybase (this time on Mac - it
> > sort of installs on Tiger, but the preferences pane is broken...
> > someday I'll figure out a manual startup procedure).
> >
> >> Did the old code get the PKs before starting the main
> >> commitChanges() transaction?
> >
> > Yes it did, resulting in inconsistency between Cayenne-managed
> > transactions and container transactions.
> >
> >> I was thinking it might be starting a new transaction before
> >> calling the PK generator ...
> >
> > I am thinking along the same lines. To make it clean, such
> > transaction has to run in a thread separate from the user transaction
> > thread. A PkGenerator may keep an idle "PK thread" that waits until a
> > request from a user thread comes in for a PK and the local cache is
> > exhausted. When this happens, the PK thread awakes, obtains a
> > connection (outside of the user transaction, effectively starting its
> > own parallel transaction), fills PK cache with new range of values,
> > notifies the user thread, and goes back to the idle state.
> >
> > This shouldn't add too much overhead (and such overhead can be
> > reduced by increasing the PK cache size), still I would say we make
> > this behavior an optional setting that can be tweaked on
> > JdbcPkGenerator.
> >
> > I'd say we add it to 3.0 (we have a separate branch for high priority
> > issues that can't be included in 1.2).
> >
> > Andrus
> >
> >
> > On Jun 30, 2006, at 3:05 PM, Gentry, Michael ((Contractor)) wrote:
> >> I was thinking it might be starting a new transaction before
> >> calling the
> >> PK generator ... Did the old code get the PKs before starting the
> >> main
> >> commitChanges() transaction?
> >>
> >> I actually wasn't managing the auto-commit manually. I was just
> >> using
> >> the connection and it was working, prior to M12. I didn't know the
> >> auto-commit value prior to the problem. :-)
> >>
> >> The last part of your message sounds a bit frightening ...
> >>
> >> I just looked at the current Sybase PK generator and it grabs the
> >> connection, just like I'm doing, and calls the auto_pk_for_table
> >> stored
> >> procedure. Isn't there a chance that generator could fail now,
> >> too? I
> >> think there is a way when creating the SP to tell Sybase to make it
> >> unchained, but the current code doesn't specify that. (I'd have to
> >> Google search again to find the right SQL.)
> >>
> >> Thanks,
> >>
> >> /dev/mrg
> >>
> >> PS. Changing the chaining mode of the SP might not be possible for
> >> us.
> >>
> >>
> >> -----Original Message-----
> >> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
> >> Sent: Friday, June 30, 2006 12:58 PM
> >> To: cayenne-dev@incubator.apache.org
> >> Subject: Re: Sybase adapter changes?
> >>
> >>
> >> Ok, I see. The new code wraps PK generator in the main transaction,
> >> so I can see how managing auto-commit property manually in your
> >> custom generator can get you in trouble. One possible workaround may
> >> be using a separate connection ... which DataNode makes really hard
> >> by returning a wrapper inner class when in transaction. So you may
> >> need to unbind the transaction from the thread, call
> >> DataNode.getDataSource(), then rebind transaction back.
> >>
> >> Andrus
> >>
> >>
> >> On Jun 30, 2006, at 3:38 PM, Gentry, Michael ((Contractor)) wrote:
> >>
> >>> Judging by the release notes at:
> >>>
> >>> http://www.objectstyle.org/confluence/display/CAY/2006/03/23/Cayenne
> >>> +ORM
> >>> +1.2M12+Release
> >>>
> >>> I'd guess the nested DataContexts are a likely place to look?
> >>>
> >>> Of course, that brings up the question: is this a bug that should be
> >>> fixed or should I just update my PK generator to store the auto-
> >>> commit
> >>> flag, set it true for my usage, then set it back to the original
> >>> value?
> >>> Also, do you think this would effect running stored procedures
> >>> through
> >>> Cayenne instead of JDBC directly, too?
> >>>
> >>> Thanks,
> >>>
> >>> /dev/mrg
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
> >>> Sent: Friday, June 30, 2006 10:33 AM
> >>> To: cayenne-dev@incubator.apache.org
> >>> Subject: Re: Sybase adapter changes?
> >>>
> >>>
> >>> IIRC transaction API changes also happened around M12.
> >>>
> >>> Andrus
> >>>
> >>> On Jun 30, 2006, at 3:19 PM, Gentry, Michael ((Contractor)) wrote:
> >>>
> >>>> M9: Pass (auto-commit = true)
> >>>> M10: Pass (auto-commit = true)
> >>>> M11: Pass (auto-commit = true)
> >>>> M12: Fail (auto-commit = false)
> >>>> RC1: Fail (auto-commit = false)
> >>>>
> >>>> Well, at least that provides a good starting point. :-)
> >>>>
> >>>> /dev/mrg
> >>>>
> >>
> >>
> >
> >
>
>
Re: Sybase adapter changes?
Posted by Andrus Adamchik <an...@objectstyle.org>.
If you want to go that way, I suggest caching a DataSource, not
Connection.
BTW, I am in the process of installing Panther on my old laptop to
give Sybase installation another try.
Andrus
On Jul 6, 2006, at 2:02 PM, Gentry, Michael ((Contractor)) wrote:
> I have a feeling I know the answer to this already ... Would
> dataNode.getDataSource() always return a PoolManager object? (I'm
> guessing no.)
>
> I was thinking of maybe getting the username/password/jdbc:/etc
> from it
> and opening (and caching) a PK connection. Seems a bit inefficient,
> though, holding a connection only for PK generation. I suspect this
> isn't really what you had in mind, though ...
>
> /dev/mrg
>
>
> -----Original Message-----
> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
> Sent: Monday, July 03, 2006 9:33 PM
> To: cayenne-dev@incubator.apache.org
> Subject: Re: Sybase adapter changes?
>
>
> Ok, another failed attempt installing Sybase (this time on Mac - it
> sort of installs on Tiger, but the preferences pane is broken...
> someday I'll figure out a manual startup procedure).
>
>> Did the old code get the PKs before starting the main
>> commitChanges() transaction?
>
> Yes it did, resulting in inconsistency between Cayenne-managed
> transactions and container transactions.
>
>> I was thinking it might be starting a new transaction before
>> calling the PK generator ...
>
> I am thinking along the same lines. To make it clean, such
> transaction has to run in a thread separate from the user transaction
> thread. A PkGenerator may keep an idle "PK thread" that waits until a
> request from a user thread comes in for a PK and the local cache is
> exhausted. When this happens, the PK thread awakes, obtains a
> connection (outside of the user transaction, effectively starting its
> own parallel transaction), fills PK cache with new range of values,
> notifies the user thread, and goes back to the idle state.
>
> This shouldn't add too much overhead (and such overhead can be
> reduced by increasing the PK cache size), still I would say we make
> this behavior an optional setting that can be tweaked on
> JdbcPkGenerator.
>
> I'd say we add it to 3.0 (we have a separate branch for high priority
> issues that can't be included in 1.2).
>
> Andrus
>
>
> On Jun 30, 2006, at 3:05 PM, Gentry, Michael ((Contractor)) wrote:
>> I was thinking it might be starting a new transaction before
>> calling the
>> PK generator ... Did the old code get the PKs before starting the
>> main
>> commitChanges() transaction?
>>
>> I actually wasn't managing the auto-commit manually. I was just
>> using
>> the connection and it was working, prior to M12. I didn't know the
>> auto-commit value prior to the problem. :-)
>>
>> The last part of your message sounds a bit frightening ...
>>
>> I just looked at the current Sybase PK generator and it grabs the
>> connection, just like I'm doing, and calls the auto_pk_for_table
>> stored
>> procedure. Isn't there a chance that generator could fail now,
>> too? I
>> think there is a way when creating the SP to tell Sybase to make it
>> unchained, but the current code doesn't specify that. (I'd have to
>> Google search again to find the right SQL.)
>>
>> Thanks,
>>
>> /dev/mrg
>>
>> PS. Changing the chaining mode of the SP might not be possible for
>> us.
>>
>>
>> -----Original Message-----
>> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
>> Sent: Friday, June 30, 2006 12:58 PM
>> To: cayenne-dev@incubator.apache.org
>> Subject: Re: Sybase adapter changes?
>>
>>
>> Ok, I see. The new code wraps PK generator in the main transaction,
>> so I can see how managing auto-commit property manually in your
>> custom generator can get you in trouble. One possible workaround may
>> be using a separate connection ... which DataNode makes really hard
>> by returning a wrapper inner class when in transaction. So you may
>> need to unbind the transaction from the thread, call
>> DataNode.getDataSource(), then rebind transaction back.
>>
>> Andrus
>>
>>
>> On Jun 30, 2006, at 3:38 PM, Gentry, Michael ((Contractor)) wrote:
>>
>>> Judging by the release notes at:
>>>
>>> http://www.objectstyle.org/confluence/display/CAY/2006/03/23/Cayenne
>>> +ORM
>>> +1.2M12+Release
>>>
>>> I'd guess the nested DataContexts are a likely place to look?
>>>
>>> Of course, that brings up the question: is this a bug that should be
>>> fixed or should I just update my PK generator to store the auto-
>>> commit
>>> flag, set it true for my usage, then set it back to the original
>>> value?
>>> Also, do you think this would effect running stored procedures
>>> through
>>> Cayenne instead of JDBC directly, too?
>>>
>>> Thanks,
>>>
>>> /dev/mrg
>>>
>>>
>>> -----Original Message-----
>>> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
>>> Sent: Friday, June 30, 2006 10:33 AM
>>> To: cayenne-dev@incubator.apache.org
>>> Subject: Re: Sybase adapter changes?
>>>
>>>
>>> IIRC transaction API changes also happened around M12.
>>>
>>> Andrus
>>>
>>> On Jun 30, 2006, at 3:19 PM, Gentry, Michael ((Contractor)) wrote:
>>>
>>>> M9: Pass (auto-commit = true)
>>>> M10: Pass (auto-commit = true)
>>>> M11: Pass (auto-commit = true)
>>>> M12: Fail (auto-commit = false)
>>>> RC1: Fail (auto-commit = false)
>>>>
>>>> Well, at least that provides a good starting point. :-)
>>>>
>>>> /dev/mrg
>>>>
>>
>>
>
>
RE: Sybase adapter changes?
Posted by "Gentry, Michael (Contractor)" <mi...@fanniemae.com>.
I have a feeling I know the answer to this already ... Would
dataNode.getDataSource() always return a PoolManager object? (I'm
guessing no.)
I was thinking of maybe getting the username/password/jdbc:/etc from it
and opening (and caching) a PK connection. Seems a bit inefficient,
though, holding a connection only for PK generation. I suspect this
isn't really what you had in mind, though ...
/dev/mrg
-----Original Message-----
From: Andrus Adamchik [mailto:andrus@objectstyle.org]
Sent: Monday, July 03, 2006 9:33 PM
To: cayenne-dev@incubator.apache.org
Subject: Re: Sybase adapter changes?
Ok, another failed attempt installing Sybase (this time on Mac - it
sort of installs on Tiger, but the preferences pane is broken...
someday I'll figure out a manual startup procedure).
> Did the old code get the PKs before starting the main
> commitChanges() transaction?
Yes it did, resulting in inconsistency between Cayenne-managed
transactions and container transactions.
> I was thinking it might be starting a new transaction before
> calling the PK generator ...
I am thinking along the same lines. To make it clean, such
transaction has to run in a thread separate from the user transaction
thread. A PkGenerator may keep an idle "PK thread" that waits until a
request from a user thread comes in for a PK and the local cache is
exhausted. When this happens, the PK thread awakes, obtains a
connection (outside of the user transaction, effectively starting its
own parallel transaction), fills PK cache with new range of values,
notifies the user thread, and goes back to the idle state.
This shouldn't add too much overhead (and such overhead can be
reduced by increasing the PK cache size), still I would say we make
this behavior an optional setting that can be tweaked on
JdbcPkGenerator.
I'd say we add it to 3.0 (we have a separate branch for high priority
issues that can't be included in 1.2).
Andrus
On Jun 30, 2006, at 3:05 PM, Gentry, Michael ((Contractor)) wrote:
> I was thinking it might be starting a new transaction before
> calling the
> PK generator ... Did the old code get the PKs before starting the
> main
> commitChanges() transaction?
>
> I actually wasn't managing the auto-commit manually. I was just using
> the connection and it was working, prior to M12. I didn't know the
> auto-commit value prior to the problem. :-)
>
> The last part of your message sounds a bit frightening ...
>
> I just looked at the current Sybase PK generator and it grabs the
> connection, just like I'm doing, and calls the auto_pk_for_table
> stored
> procedure. Isn't there a chance that generator could fail now,
> too? I
> think there is a way when creating the SP to tell Sybase to make it
> unchained, but the current code doesn't specify that. (I'd have to
> Google search again to find the right SQL.)
>
> Thanks,
>
> /dev/mrg
>
> PS. Changing the chaining mode of the SP might not be possible for us.
>
>
> -----Original Message-----
> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
> Sent: Friday, June 30, 2006 12:58 PM
> To: cayenne-dev@incubator.apache.org
> Subject: Re: Sybase adapter changes?
>
>
> Ok, I see. The new code wraps PK generator in the main transaction,
> so I can see how managing auto-commit property manually in your
> custom generator can get you in trouble. One possible workaround may
> be using a separate connection ... which DataNode makes really hard
> by returning a wrapper inner class when in transaction. So you may
> need to unbind the transaction from the thread, call
> DataNode.getDataSource(), then rebind transaction back.
>
> Andrus
>
>
> On Jun 30, 2006, at 3:38 PM, Gentry, Michael ((Contractor)) wrote:
>
>> Judging by the release notes at:
>>
>> http://www.objectstyle.org/confluence/display/CAY/2006/03/23/Cayenne
>> +ORM
>> +1.2M12+Release
>>
>> I'd guess the nested DataContexts are a likely place to look?
>>
>> Of course, that brings up the question: is this a bug that should be
>> fixed or should I just update my PK generator to store the auto-
>> commit
>> flag, set it true for my usage, then set it back to the original
>> value?
>> Also, do you think this would effect running stored procedures
>> through
>> Cayenne instead of JDBC directly, too?
>>
>> Thanks,
>>
>> /dev/mrg
>>
>>
>> -----Original Message-----
>> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
>> Sent: Friday, June 30, 2006 10:33 AM
>> To: cayenne-dev@incubator.apache.org
>> Subject: Re: Sybase adapter changes?
>>
>>
>> IIRC transaction API changes also happened around M12.
>>
>> Andrus
>>
>> On Jun 30, 2006, at 3:19 PM, Gentry, Michael ((Contractor)) wrote:
>>
>>> M9: Pass (auto-commit = true)
>>> M10: Pass (auto-commit = true)
>>> M11: Pass (auto-commit = true)
>>> M12: Fail (auto-commit = false)
>>> RC1: Fail (auto-commit = false)
>>>
>>> Well, at least that provides a good starting point. :-)
>>>
>>> /dev/mrg
>>>
>
>
Re: Sybase adapter changes?
Posted by Andrus Adamchik <an...@objectstyle.org>.
Ok, another failed attempt installing Sybase (this time on Mac - it
sort of installs on Tiger, but the preferences pane is broken...
someday I'll figure out a manual startup procedure).
> Did the old code get the PKs before starting the main
> commitChanges() transaction?
Yes it did, resulting in inconsistency between Cayenne-managed
transactions and container transactions.
> I was thinking it might be starting a new transaction before
> calling the PK generator ...
I am thinking along the same lines. To make it clean, such
transaction has to run in a thread separate from the user transaction
thread. A PkGenerator may keep an idle "PK thread" that waits until a
request from a user thread comes in for a PK and the local cache is
exhausted. When this happens, the PK thread awakes, obtains a
connection (outside of the user transaction, effectively starting its
own parallel transaction), fills PK cache with new range of values,
notifies the user thread, and goes back to the idle state.
This shouldn't add too much overhead (and such overhead can be
reduced by increasing the PK cache size), still I would say we make
this behavior an optional setting that can be tweaked on
JdbcPkGenerator.
I'd say we add it to 3.0 (we have a separate branch for high priority
issues that can't be included in 1.2).
Andrus
On Jun 30, 2006, at 3:05 PM, Gentry, Michael ((Contractor)) wrote:
> I was thinking it might be starting a new transaction before
> calling the
> PK generator ... Did the old code get the PKs before starting the
> main
> commitChanges() transaction?
>
> I actually wasn't managing the auto-commit manually. I was just using
> the connection and it was working, prior to M12. I didn't know the
> auto-commit value prior to the problem. :-)
>
> The last part of your message sounds a bit frightening ...
>
> I just looked at the current Sybase PK generator and it grabs the
> connection, just like I'm doing, and calls the auto_pk_for_table
> stored
> procedure. Isn't there a chance that generator could fail now,
> too? I
> think there is a way when creating the SP to tell Sybase to make it
> unchained, but the current code doesn't specify that. (I'd have to
> Google search again to find the right SQL.)
>
> Thanks,
>
> /dev/mrg
>
> PS. Changing the chaining mode of the SP might not be possible for us.
>
>
> -----Original Message-----
> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
> Sent: Friday, June 30, 2006 12:58 PM
> To: cayenne-dev@incubator.apache.org
> Subject: Re: Sybase adapter changes?
>
>
> Ok, I see. The new code wraps PK generator in the main transaction,
> so I can see how managing auto-commit property manually in your
> custom generator can get you in trouble. One possible workaround may
> be using a separate connection ... which DataNode makes really hard
> by returning a wrapper inner class when in transaction. So you may
> need to unbind the transaction from the thread, call
> DataNode.getDataSource(), then rebind transaction back.
>
> Andrus
>
>
> On Jun 30, 2006, at 3:38 PM, Gentry, Michael ((Contractor)) wrote:
>
>> Judging by the release notes at:
>>
>> http://www.objectstyle.org/confluence/display/CAY/2006/03/23/Cayenne
>> +ORM
>> +1.2M12+Release
>>
>> I'd guess the nested DataContexts are a likely place to look?
>>
>> Of course, that brings up the question: is this a bug that should be
>> fixed or should I just update my PK generator to store the auto-
>> commit
>> flag, set it true for my usage, then set it back to the original
>> value?
>> Also, do you think this would effect running stored procedures
>> through
>> Cayenne instead of JDBC directly, too?
>>
>> Thanks,
>>
>> /dev/mrg
>>
>>
>> -----Original Message-----
>> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
>> Sent: Friday, June 30, 2006 10:33 AM
>> To: cayenne-dev@incubator.apache.org
>> Subject: Re: Sybase adapter changes?
>>
>>
>> IIRC transaction API changes also happened around M12.
>>
>> Andrus
>>
>> On Jun 30, 2006, at 3:19 PM, Gentry, Michael ((Contractor)) wrote:
>>
>>> M9: Pass (auto-commit = true)
>>> M10: Pass (auto-commit = true)
>>> M11: Pass (auto-commit = true)
>>> M12: Fail (auto-commit = false)
>>> RC1: Fail (auto-commit = false)
>>>
>>> Well, at least that provides a good starting point. :-)
>>>
>>> /dev/mrg
>>>
>
>
RE: Sybase adapter changes?
Posted by "Gentry, Michael (Contractor)" <mi...@fanniemae.com>.
I was thinking it might be starting a new transaction before calling the
PK generator ... Did the old code get the PKs before starting the main
commitChanges() transaction?
I actually wasn't managing the auto-commit manually. I was just using
the connection and it was working, prior to M12. I didn't know the
auto-commit value prior to the problem. :-)
The last part of your message sounds a bit frightening ...
I just looked at the current Sybase PK generator and it grabs the
connection, just like I'm doing, and calls the auto_pk_for_table stored
procedure. Isn't there a chance that generator could fail now, too? I
think there is a way when creating the SP to tell Sybase to make it
unchained, but the current code doesn't specify that. (I'd have to
Google search again to find the right SQL.)
Thanks,
/dev/mrg
PS. Changing the chaining mode of the SP might not be possible for us.
-----Original Message-----
From: Andrus Adamchik [mailto:andrus@objectstyle.org]
Sent: Friday, June 30, 2006 12:58 PM
To: cayenne-dev@incubator.apache.org
Subject: Re: Sybase adapter changes?
Ok, I see. The new code wraps PK generator in the main transaction,
so I can see how managing auto-commit property manually in your
custom generator can get you in trouble. One possible workaround may
be using a separate connection ... which DataNode makes really hard
by returning a wrapper inner class when in transaction. So you may
need to unbind the transaction from the thread, call
DataNode.getDataSource(), then rebind transaction back.
Andrus
On Jun 30, 2006, at 3:38 PM, Gentry, Michael ((Contractor)) wrote:
> Judging by the release notes at:
>
> http://www.objectstyle.org/confluence/display/CAY/2006/03/23/Cayenne
> +ORM
> +1.2M12+Release
>
> I'd guess the nested DataContexts are a likely place to look?
>
> Of course, that brings up the question: is this a bug that should be
> fixed or should I just update my PK generator to store the auto-commit
> flag, set it true for my usage, then set it back to the original
> value?
> Also, do you think this would effect running stored procedures through
> Cayenne instead of JDBC directly, too?
>
> Thanks,
>
> /dev/mrg
>
>
> -----Original Message-----
> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
> Sent: Friday, June 30, 2006 10:33 AM
> To: cayenne-dev@incubator.apache.org
> Subject: Re: Sybase adapter changes?
>
>
> IIRC transaction API changes also happened around M12.
>
> Andrus
>
> On Jun 30, 2006, at 3:19 PM, Gentry, Michael ((Contractor)) wrote:
>
>> M9: Pass (auto-commit = true)
>> M10: Pass (auto-commit = true)
>> M11: Pass (auto-commit = true)
>> M12: Fail (auto-commit = false)
>> RC1: Fail (auto-commit = false)
>>
>> Well, at least that provides a good starting point. :-)
>>
>> /dev/mrg
>>
Re: Sybase adapter changes?
Posted by Andrus Adamchik <an...@objectstyle.org>.
Ok, I see. The new code wraps PK generator in the main transaction,
so I can see how managing auto-commit property manually in your
custom generator can get you in trouble. One possible workaround may
be using a separate connection ... which DataNode makes really hard
by returning a wrapper inner class when in transaction. So you may
need to unbind the transaction from the thread, call
DataNode.getDataSource(), then rebind transaction back.
Andrus
On Jun 30, 2006, at 3:38 PM, Gentry, Michael ((Contractor)) wrote:
> Judging by the release notes at:
>
> http://www.objectstyle.org/confluence/display/CAY/2006/03/23/Cayenne
> +ORM
> +1.2M12+Release
>
> I'd guess the nested DataContexts are a likely place to look?
>
> Of course, that brings up the question: is this a bug that should be
> fixed or should I just update my PK generator to store the auto-commit
> flag, set it true for my usage, then set it back to the original
> value?
> Also, do you think this would effect running stored procedures through
> Cayenne instead of JDBC directly, too?
>
> Thanks,
>
> /dev/mrg
>
>
> -----Original Message-----
> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
> Sent: Friday, June 30, 2006 10:33 AM
> To: cayenne-dev@incubator.apache.org
> Subject: Re: Sybase adapter changes?
>
>
> IIRC transaction API changes also happened around M12.
>
> Andrus
>
> On Jun 30, 2006, at 3:19 PM, Gentry, Michael ((Contractor)) wrote:
>
>> M9: Pass (auto-commit = true)
>> M10: Pass (auto-commit = true)
>> M11: Pass (auto-commit = true)
>> M12: Fail (auto-commit = false)
>> RC1: Fail (auto-commit = false)
>>
>> Well, at least that provides a good starting point. :-)
>>
>> /dev/mrg
>>
RE: Sybase adapter changes?
Posted by "Gentry, Michael (Contractor)" <mi...@fanniemae.com>.
Judging by the release notes at:
http://www.objectstyle.org/confluence/display/CAY/2006/03/23/Cayenne+ORM
+1.2M12+Release
I'd guess the nested DataContexts are a likely place to look?
Of course, that brings up the question: is this a bug that should be
fixed or should I just update my PK generator to store the auto-commit
flag, set it true for my usage, then set it back to the original value?
Also, do you think this would effect running stored procedures through
Cayenne instead of JDBC directly, too?
Thanks,
/dev/mrg
-----Original Message-----
From: Andrus Adamchik [mailto:andrus@objectstyle.org]
Sent: Friday, June 30, 2006 10:33 AM
To: cayenne-dev@incubator.apache.org
Subject: Re: Sybase adapter changes?
IIRC transaction API changes also happened around M12.
Andrus
On Jun 30, 2006, at 3:19 PM, Gentry, Michael ((Contractor)) wrote:
> M9: Pass (auto-commit = true)
> M10: Pass (auto-commit = true)
> M11: Pass (auto-commit = true)
> M12: Fail (auto-commit = false)
> RC1: Fail (auto-commit = false)
>
> Well, at least that provides a good starting point. :-)
>
> /dev/mrg
>
>
> -----Original Message-----
> From: Gentry, Michael (Contractor)
> [mailto:michael_gentry@fanniemae.com]
>
> Sent: Friday, June 30, 2006 9:47 AM
> To: cayenne-dev@incubator.apache.org
> Subject: RE: Sybase adapter changes?
>
>
> Well, I don't really have DBA access (create table/etc) to any of our
> Sybase servers. There *might* be a development database server
> somewhere I could try it on. I'll ask around.
>
> On another note ...
>
> Installed 1.2 RC2 and ran the application. Same exception.
>
> Installed 1.2 M9 and ran the application. Generated primary key.
>
> So, something has definitely changed between those releases, but
> I'm not
> sure what. I'm not even really using Cayenne in the key generator (I
> get the JDBC connection and call it directly).
>
> /dev/mrg
>
> PS. I might try installing all the releases between the two and see
> where the breaking point is.
>
>
>
> -----Original Message-----
> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
> Sent: Friday, June 30, 2006 3:57 AM
> To: cayenne-dev@incubator.apache.org
> Subject: Re: Sybase adapter changes?
>
>
> This may be something related to the changes in the rest of Cayenne
> (such as transaction code). I've been having problems with my Linux
> Sybase installation lately (and it is not yet supported on Fedora
> Core 5, so I can't put it on our new server), so the last few
> releases haven't been tested on Sybase.
>
> Can you run Cayenne unit tests against Sybase and see if it generates
> any failures?
>
> Andrus
>
> On Jun 29, 2006, at 10:27 PM, Gentry, Michael ((Contractor)) wrote:
>> I have an application running fine "in production" using Cayenne
>> 1.2M9,
>> but when testing it locally with Cayenne 1.2 RC1, I get this
>> exception:
>>
>> Exception = com.sybase.jdbc2.jdbc.SybSQLException: Stored procedure
>> 'getpid' may be run only in unchained transaction mode. The 'SET
>> CHAINED
>> OFF' command will cause the current session to use unchained
>> transaction
>> mode.
>>
>> I didn't make any changes to the Cayenne portion, just twiddled a few
>> Tapestry bits and was testing the application out. The error occurs
>> when I insert a record and need a primary key -- I call a stored
>> procedure directly using JDBC in my custom PK class (which has been
>> working perfectly for over a year):
>>
>> public Object generatePkForDbEntity(DataNode dataNode, DbEntity
>> ent)
>> throws Exception
>> {
>> // Get our connection so we can call the stored procedure
>> Connection connection =
>> dataNode.getDataSource().getConnection();
>> CallableStatement getPID = connection.prepareCall("{call
>> getpid(?,?,?)}");
>>
>> // Prepare the stored procedure
>> getPID.setInt(1, currentBlockSize); // Slot 1:
>> Number of
>> PIDs requested
>> getPID.registerOutParameter(2, Types.BINARY); // Slot 2: First
>> PID
>> allocated
>> getPID.registerOutParameter(3, Types.INTEGER); // Slot 3:
>> Number of
>> PIDs allocated
>> try
>> {
>> // Call the stored procedure
>> getPID.execute();
>> ...
>>
>> I get the exception on the execute() line.
>>
>> I did diffs on the Sybase code, but didn't see any changes -- at
>> least
>> not since it was converted to Subversion.
>>
>> Anyone have ideas?
>>
>> Thanks!
>>
>> /dev/mrg
>>
>> PS. Auto commit is false.
>>
>
>
Re: Sybase adapter changes?
Posted by Andrus Adamchik <an...@objectstyle.org>.
IIRC transaction API changes also happened around M12.
Andrus
On Jun 30, 2006, at 3:19 PM, Gentry, Michael ((Contractor)) wrote:
> M9: Pass (auto-commit = true)
> M10: Pass (auto-commit = true)
> M11: Pass (auto-commit = true)
> M12: Fail (auto-commit = false)
> RC1: Fail (auto-commit = false)
>
> Well, at least that provides a good starting point. :-)
>
> /dev/mrg
>
>
> -----Original Message-----
> From: Gentry, Michael (Contractor)
> [mailto:michael_gentry@fanniemae.com]
>
> Sent: Friday, June 30, 2006 9:47 AM
> To: cayenne-dev@incubator.apache.org
> Subject: RE: Sybase adapter changes?
>
>
> Well, I don't really have DBA access (create table/etc) to any of our
> Sybase servers. There *might* be a development database server
> somewhere I could try it on. I'll ask around.
>
> On another note ...
>
> Installed 1.2 RC2 and ran the application. Same exception.
>
> Installed 1.2 M9 and ran the application. Generated primary key.
>
> So, something has definitely changed between those releases, but
> I'm not
> sure what. I'm not even really using Cayenne in the key generator (I
> get the JDBC connection and call it directly).
>
> /dev/mrg
>
> PS. I might try installing all the releases between the two and see
> where the breaking point is.
>
>
>
> -----Original Message-----
> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
> Sent: Friday, June 30, 2006 3:57 AM
> To: cayenne-dev@incubator.apache.org
> Subject: Re: Sybase adapter changes?
>
>
> This may be something related to the changes in the rest of Cayenne
> (such as transaction code). I've been having problems with my Linux
> Sybase installation lately (and it is not yet supported on Fedora
> Core 5, so I can't put it on our new server), so the last few
> releases haven't been tested on Sybase.
>
> Can you run Cayenne unit tests against Sybase and see if it generates
> any failures?
>
> Andrus
>
> On Jun 29, 2006, at 10:27 PM, Gentry, Michael ((Contractor)) wrote:
>> I have an application running fine "in production" using Cayenne
>> 1.2M9,
>> but when testing it locally with Cayenne 1.2 RC1, I get this
>> exception:
>>
>> Exception = com.sybase.jdbc2.jdbc.SybSQLException: Stored procedure
>> 'getpid' may be run only in unchained transaction mode. The 'SET
>> CHAINED
>> OFF' command will cause the current session to use unchained
>> transaction
>> mode.
>>
>> I didn't make any changes to the Cayenne portion, just twiddled a few
>> Tapestry bits and was testing the application out. The error occurs
>> when I insert a record and need a primary key -- I call a stored
>> procedure directly using JDBC in my custom PK class (which has been
>> working perfectly for over a year):
>>
>> public Object generatePkForDbEntity(DataNode dataNode, DbEntity
>> ent)
>> throws Exception
>> {
>> // Get our connection so we can call the stored procedure
>> Connection connection =
>> dataNode.getDataSource().getConnection();
>> CallableStatement getPID = connection.prepareCall("{call
>> getpid(?,?,?)}");
>>
>> // Prepare the stored procedure
>> getPID.setInt(1, currentBlockSize); // Slot 1:
>> Number of
>> PIDs requested
>> getPID.registerOutParameter(2, Types.BINARY); // Slot 2: First
>> PID
>> allocated
>> getPID.registerOutParameter(3, Types.INTEGER); // Slot 3:
>> Number of
>> PIDs allocated
>> try
>> {
>> // Call the stored procedure
>> getPID.execute();
>> ...
>>
>> I get the exception on the execute() line.
>>
>> I did diffs on the Sybase code, but didn't see any changes -- at
>> least
>> not since it was converted to Subversion.
>>
>> Anyone have ideas?
>>
>> Thanks!
>>
>> /dev/mrg
>>
>> PS. Auto commit is false.
>>
>
>
RE: Sybase adapter changes?
Posted by "Gentry, Michael (Contractor)" <mi...@fanniemae.com>.
M9: Pass (auto-commit = true)
M10: Pass (auto-commit = true)
M11: Pass (auto-commit = true)
M12: Fail (auto-commit = false)
RC1: Fail (auto-commit = false)
Well, at least that provides a good starting point. :-)
/dev/mrg
-----Original Message-----
From: Gentry, Michael (Contractor) [mailto:michael_gentry@fanniemae.com]
Sent: Friday, June 30, 2006 9:47 AM
To: cayenne-dev@incubator.apache.org
Subject: RE: Sybase adapter changes?
Well, I don't really have DBA access (create table/etc) to any of our
Sybase servers. There *might* be a development database server
somewhere I could try it on. I'll ask around.
On another note ...
Installed 1.2 RC2 and ran the application. Same exception.
Installed 1.2 M9 and ran the application. Generated primary key.
So, something has definitely changed between those releases, but I'm not
sure what. I'm not even really using Cayenne in the key generator (I
get the JDBC connection and call it directly).
/dev/mrg
PS. I might try installing all the releases between the two and see
where the breaking point is.
-----Original Message-----
From: Andrus Adamchik [mailto:andrus@objectstyle.org]
Sent: Friday, June 30, 2006 3:57 AM
To: cayenne-dev@incubator.apache.org
Subject: Re: Sybase adapter changes?
This may be something related to the changes in the rest of Cayenne
(such as transaction code). I've been having problems with my Linux
Sybase installation lately (and it is not yet supported on Fedora
Core 5, so I can't put it on our new server), so the last few
releases haven't been tested on Sybase.
Can you run Cayenne unit tests against Sybase and see if it generates
any failures?
Andrus
On Jun 29, 2006, at 10:27 PM, Gentry, Michael ((Contractor)) wrote:
> I have an application running fine "in production" using Cayenne
> 1.2M9,
> but when testing it locally with Cayenne 1.2 RC1, I get this
> exception:
>
> Exception = com.sybase.jdbc2.jdbc.SybSQLException: Stored procedure
> 'getpid' may be run only in unchained transaction mode. The 'SET
> CHAINED
> OFF' command will cause the current session to use unchained
> transaction
> mode.
>
> I didn't make any changes to the Cayenne portion, just twiddled a few
> Tapestry bits and was testing the application out. The error occurs
> when I insert a record and need a primary key -- I call a stored
> procedure directly using JDBC in my custom PK class (which has been
> working perfectly for over a year):
>
> public Object generatePkForDbEntity(DataNode dataNode, DbEntity ent)
> throws Exception
> {
> // Get our connection so we can call the stored procedure
> Connection connection =
> dataNode.getDataSource().getConnection();
> CallableStatement getPID = connection.prepareCall("{call
> getpid(?,?,?)}");
>
> // Prepare the stored procedure
> getPID.setInt(1, currentBlockSize); // Slot 1:
> Number of
> PIDs requested
> getPID.registerOutParameter(2, Types.BINARY); // Slot 2: First
> PID
> allocated
> getPID.registerOutParameter(3, Types.INTEGER); // Slot 3:
> Number of
> PIDs allocated
> try
> {
> // Call the stored procedure
> getPID.execute();
> ...
>
> I get the exception on the execute() line.
>
> I did diffs on the Sybase code, but didn't see any changes -- at least
> not since it was converted to Subversion.
>
> Anyone have ideas?
>
> Thanks!
>
> /dev/mrg
>
> PS. Auto commit is false.
>
RE: Sybase adapter changes?
Posted by "Gentry, Michael (Contractor)" <mi...@fanniemae.com>.
Well, I don't really have DBA access (create table/etc) to any of our
Sybase servers. There *might* be a development database server
somewhere I could try it on. I'll ask around.
On another note ...
Installed 1.2 RC2 and ran the application. Same exception.
Installed 1.2 M9 and ran the application. Generated primary key.
So, something has definitely changed between those releases, but I'm not
sure what. I'm not even really using Cayenne in the key generator (I
get the JDBC connection and call it directly).
/dev/mrg
PS. I might try installing all the releases between the two and see
where the breaking point is.
-----Original Message-----
From: Andrus Adamchik [mailto:andrus@objectstyle.org]
Sent: Friday, June 30, 2006 3:57 AM
To: cayenne-dev@incubator.apache.org
Subject: Re: Sybase adapter changes?
This may be something related to the changes in the rest of Cayenne
(such as transaction code). I've been having problems with my Linux
Sybase installation lately (and it is not yet supported on Fedora
Core 5, so I can't put it on our new server), so the last few
releases haven't been tested on Sybase.
Can you run Cayenne unit tests against Sybase and see if it generates
any failures?
Andrus
On Jun 29, 2006, at 10:27 PM, Gentry, Michael ((Contractor)) wrote:
> I have an application running fine "in production" using Cayenne
> 1.2M9,
> but when testing it locally with Cayenne 1.2 RC1, I get this
> exception:
>
> Exception = com.sybase.jdbc2.jdbc.SybSQLException: Stored procedure
> 'getpid' may be run only in unchained transaction mode. The 'SET
> CHAINED
> OFF' command will cause the current session to use unchained
> transaction
> mode.
>
> I didn't make any changes to the Cayenne portion, just twiddled a few
> Tapestry bits and was testing the application out. The error occurs
> when I insert a record and need a primary key -- I call a stored
> procedure directly using JDBC in my custom PK class (which has been
> working perfectly for over a year):
>
> public Object generatePkForDbEntity(DataNode dataNode, DbEntity ent)
> throws Exception
> {
> // Get our connection so we can call the stored procedure
> Connection connection =
> dataNode.getDataSource().getConnection();
> CallableStatement getPID = connection.prepareCall("{call
> getpid(?,?,?)}");
>
> // Prepare the stored procedure
> getPID.setInt(1, currentBlockSize); // Slot 1:
> Number of
> PIDs requested
> getPID.registerOutParameter(2, Types.BINARY); // Slot 2: First
> PID
> allocated
> getPID.registerOutParameter(3, Types.INTEGER); // Slot 3:
> Number of
> PIDs allocated
> try
> {
> // Call the stored procedure
> getPID.execute();
> ...
>
> I get the exception on the execute() line.
>
> I did diffs on the Sybase code, but didn't see any changes -- at least
> not since it was converted to Subversion.
>
> Anyone have ideas?
>
> Thanks!
>
> /dev/mrg
>
> PS. Auto commit is false.
>
Re: Sybase adapter changes?
Posted by Andrus Adamchik <an...@objectstyle.org>.
This may be something related to the changes in the rest of Cayenne
(such as transaction code). I've been having problems with my Linux
Sybase installation lately (and it is not yet supported on Fedora
Core 5, so I can't put it on our new server), so the last few
releases haven't been tested on Sybase.
Can you run Cayenne unit tests against Sybase and see if it generates
any failures?
Andrus
On Jun 29, 2006, at 10:27 PM, Gentry, Michael ((Contractor)) wrote:
> I have an application running fine "in production" using Cayenne
> 1.2M9,
> but when testing it locally with Cayenne 1.2 RC1, I get this
> exception:
>
> Exception = com.sybase.jdbc2.jdbc.SybSQLException: Stored procedure
> 'getpid' may be run only in unchained transaction mode. The 'SET
> CHAINED
> OFF' command will cause the current session to use unchained
> transaction
> mode.
>
> I didn't make any changes to the Cayenne portion, just twiddled a few
> Tapestry bits and was testing the application out. The error occurs
> when I insert a record and need a primary key -- I call a stored
> procedure directly using JDBC in my custom PK class (which has been
> working perfectly for over a year):
>
> public Object generatePkForDbEntity(DataNode dataNode, DbEntity ent)
> throws Exception
> {
> // Get our connection so we can call the stored procedure
> Connection connection =
> dataNode.getDataSource().getConnection();
> CallableStatement getPID = connection.prepareCall("{call
> getpid(?,?,?)}");
>
> // Prepare the stored procedure
> getPID.setInt(1, currentBlockSize); // Slot 1:
> Number of
> PIDs requested
> getPID.registerOutParameter(2, Types.BINARY); // Slot 2: First
> PID
> allocated
> getPID.registerOutParameter(3, Types.INTEGER); // Slot 3:
> Number of
> PIDs allocated
> try
> {
> // Call the stored procedure
> getPID.execute();
> ...
>
> I get the exception on the execute() line.
>
> I did diffs on the Sybase code, but didn't see any changes -- at least
> not since it was converted to Subversion.
>
> Anyone have ideas?
>
> Thanks!
>
> /dev/mrg
>
> PS. Auto commit is false.
>