It's not wrong, I suppose, if you're doing direct custom access to the database. In that case, you would actually benefit from multiple database channels. But you're not going to benefit from EOF :)
ms
On Aug 26, 2010, at 11:55 PM, Chuck Hill wrote:
> 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 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
>
>
>
>
>
>
>
This archive was generated by hypermail 2.0.0 : Fri Aug 27 2010 - 05:12:57 UTC