I remember those docs. I think they are just wrong. Chuck
On Aug 26, 2010, at 10:21 PM, Dov Rosenberg wrote: > Looking thru some old EOF documentation (v5.2) I found - > http://developer.apple.com/legacy/mac/library/documentation/WebObjects/Enterprise_Objects/EnterpriseObjects.pdf > > The second step in instrumenting multithreading in an Enterprise Objects > application is determining what > kind of concurrency you need. This requires knowing (or predicting) the > bottlenecks within your application. > Do bottlenecks occur at the database level when multiple users attempt > concurrent access to the data source > so that adding more database channels alleviates the bottleneck? Do > bottlenecks occur elsewhere in the > access layer so that providing a separate access layer for each user > alleviates the bottleneck? > The answers to these questions help determine the mechanism you need to use > to instrument concurrency > within an Enterprise Objects application. Two common design patterns for > concurrency within Enterprise > Objects applications are to: > ■ Provide each user with an independent access layer stack. > ■ Provide multiple database channels on demand. > > The doc goes onto say that using multiple OSC introduces additional > challenges with concurrency between OSC’s. > > The doc even gives code samples on providing multiple OSC and adding > additional database channels when a DatabaseChannelNeededNotification is > received > > I am interested to hear your analysis of the Wonder code. I will keep > experimenting > > Dov > > On 8/26/10 9:58 PM, "Mike Schrag" <[email protected]> wrote: > >> I can't vouch for connectionbroker's accuracy of impl, but I would expect all >> your db access to be behind a single lock and therefore not benefit from >> multiple channels. Of course most of the people who might challenge my claims >> are probably drunk in Montreal right now. I'll check source later tonight and >> see if I'm talking crazy. >> >> Sent from my iPhone >> >> On Aug 26, 2010, at 9:55 PM, Dov Rosenberg <[email protected]> wrote: >> >>> Is it not a good idea to use the ERXJDBCAdaptor and ConnectionBroker >>> together? >>> >>> I would have thought if I only used a single OSC it would have made sure >>> that each transaction went to the correct connection. >>> >>> Should there only be a single db connection for each OSC? >>> >>> Thanks >>> >>> Dov Rosenberg >>> >>> >>> On 8/26/10 9:46 PM, "Mike Schrag" <[email protected]> wrote: >>> >>>> With one osc you saw activity on multiple connections concurrently? I can't >>>> imagine that scenario has a happy ending. I don't even know how I would be >>>> possible given that all your db access should be behind a dbc lock. You >>>> might >>>> see use of multiple connections, but that would probably explain your >>>> failing >>>> commits (inserting on conn 1, committing conn 2, maybe). Each osc should >>>> end >>>> up having its own conn and you should see parallel access that way. >>>> >>>> To answer more I think I need to not be on an iPhone :) >>>> >>>> Sent from my iPhone >>>> >>>> On Aug 26, 2010, at 9:37 PM, Dov Rosenberg <[email protected]> wrote: >>>> >>>>> Hmmm - I did a little jmeter test and definitely saw an improvement in >>>>> page >>>>> view performance and saw activity on multiple DB connections during the >>>>> test. By simply adding the connection broker with a single OSC. >>>>> >>>>> If I set up object store pooling wont that increase issues with >>>>> concurrency >>>>> within my app? I.e. Trying to update data that has already been updated >>>>> in >>>> a >>>>> different OSC? >>>>> >>>>> I am using the Jgroups synchronizer between instances already. >>>>> >>>>> Would the following set of properties be consistent with each other: >>>>> >>>>> er.extensions.ERXObjectStoreCoordinatorPool.maxCoordinators = 10 >>>>> er.extensions.ERXJDBCAdaptor.className=er.extensions.jdbc.ERXJDBCAdaptor >>>>> er.extensions.ERXJDBCAdaptor.useConnectionBroker = true >>>>> er.extensions.remoteSynchronizer.enabled=true >>>>> er.extensions.remoteSynchronizer=er.jgroups.ERJGroupsSynchronizer >>>>> dbMinConnectionsGLOBAL=10 >>>>> dbMaxConnectionsGLOBAL=15 >>>>> er.extensions.ERXJDBCConnectionBroker.maxConnections=15 >>>>> er.extensions.ERXJDBCConnectionBroker.minConnections=10 >>>>> >>>>> If I understand what is going on I should get 10 EOF stacks sharing a pool >>>>> of 15 database connections. I assume there is some magic running behind >>>>> the >>>>> scenes to keep all of the OSC in sync with each other? >>>>> >>>>> Thanks again >>>>> >>>>> Dov Rosenberg >>>>> >>>>> >>>>> >>>>> On 8/26/10 9:00 PM, "Mike Schrag" <[email protected]> wrote: >>>>> >>>>>> Connection pooling won't really do anything for you because each stack is >>>>>> single threaded. You want object store coordinator pooling. >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>> On Aug 26, 2010, at 8:45 PM, Dov Rosenberg <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> During some testing today I turned on support for connection pooling in >>>>>>> my >>>>>>> application using the ERXJDBCAdaptor and the ERXJDBCConnectionBroker. I >>>>>>> could >>>>>>> see the connections being used fine and all of the things that did >>>>>>> fetches >>>>>>> seemed to work without any issues. However when I tried doing something >>>>>>> that >>>>>>> generated an INSERT the transactions did not commit and no changes were >>>>>>> made. >>>>>>> I could see the SQL being generated as expected and the saveChanges() >>>>>>> happened without throwing any exception – just no data got written to >>>>>>> the >>>>>>> database. As soon as I disabled the use of the connection pool >>>>>>> everything >>>>>>> worked properly again. >>>>>>> >>>>>>> Any thoughts would be appreciated >>>>>>> >>>>>>> Dov Rosenberg >>>>>>> _______________________________________________ >>>>>>> Do not post admin requests to the list. They will be ignored. >>>>>>> Webobjects-dev mailing list ([email protected]) >>>>>>> Help/Unsubscribe/Update your Subscription: >>>>>>> http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40pobox.com >>>>>>> >>>>>>> This email sent to [email protected] >>>>> >>> > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net > > This email sent to [email protected] -- Chuck Hill Senior Consultant / VP Development Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
