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:16:46 EDT