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" <mschrag@pobox.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 <DRosenberg@Inquira.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" <mschrag@pobox.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 <DRosenberg@Inquira.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" <mschrag@pobox.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 <DRosenberg@Inquira.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 ¡V 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-dev@lists.apple.com)
>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>> http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40pobox.com
>>>>>>
>>>>>> This email sent to mschrag@pobox.com
>>>>
>>
This archive was generated by hypermail 2.0.0 : Fri Aug 27 2010 - 02:22:31 UTC