On Aug 26, 2010, at 9:58 PM, Mike Schrag 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.
Hey! I resemble that comment!
> I'll check source later tonight and see if I'm talking crazy.
I think you are correct. An single EOF stack will use a single DB connection unless you do something very odd like trip a fault in awakeFromFetch while EOF is already fetching. For concurrent DB access you need to have multiple EOF stacks or multi-threaded EOF*.
Chuck
* See Unicorn.
> 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:01 UTC