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" <mschra..obox.com> 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 <DRosenber..nquira.Com> 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" <mschra..obox.com> 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 <DRosenber..nquira.Com> 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" <mschra..obox.com> 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 <DRosenber..nquira.Com> 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 (Webobjects-de..ists.apple.com)
>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>> http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40pobox.com
>>>>>>>
>>>>>>> This email sent to mschra..obox.com
>>>>>
>>>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (Webobjects-de..ists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net
>
> This email sent to chil..lobal-village.net
-- Chuck Hill Senior Consultant / VP DevelopmentPractical 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
This archive was generated by hypermail 2.0.0 : Fri Aug 27 2010 - 03:55:59 UTC