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: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 - 16:02:43 EDT