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:andru..bjectstyle.org]
Sent: Monday, July 03, 2006 9:33 PM
To: cayenne-de..ncubator.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:andru..bjectstyle.org]
> Sent: Friday, June 30, 2006 12:58 PM
> To: cayenne-de..ncubator.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:andru..bjectstyle.org]
>> Sent: Friday, June 30, 2006 10:33 AM
>> To: cayenne-de..ncubator.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
>>>
>
>
This archive was generated by hypermail 2.0.0 : Thu Jul 06 2006 - 14:02:51 EDT