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 <andru..bjectstyle.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: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 - 18:44:39 EDT