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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > Sent: Monday, July 03, 2006 9:33 PM > To: [email protected] > 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:[EMAIL PROTECTED] >> Sent: Friday, June 30, 2006 12:58 PM >> To: [email protected] >> 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:[EMAIL PROTECTED] >>> Sent: Friday, June 30, 2006 10:33 AM >>> To: [email protected] >>> 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 >>>> >> >> > >
