Re: Question about jdbc connection pool
Re: Question about jdbc connection pool
- Subject: Re: Question about jdbc connection pool
- From: Pascal Robert <email@hidden>
- Date: Tue, 07 Jun 2016 00:17:42 +0000
- Thread-topic: Question about jdbc connection pool
> Le 6 juin 2016 à 20:04, Ramsey Gurley <email@hidden> a écrit :
>
> On Jun 6, 2016, at 4:21 PM, Tarun Reddy <email@hidden> wrote:
>
>> Huh. Never knew this (serial DB access). Is there a recommended way of scaling out a WebObjects/Wonder application that doesn’t involve many, many JVMs?
>
>
> You don’t need multiple VMs to run multiple WO app instances. monitor is not like tomcat, it can run more than one instance of the same app. Each application instance gets its own jdbc connection. You can create as many instances as memory will allow.
>
> In each instance, one OSC is the default. EOObjectStoreCoordinator.defaultObjectStore(). You can create as many OSCs as memory will allow and use them however you like. Each OSC will get its own connection. ERXEC.newEditingContext(myOSC);
>
> If you want, you can use one OSC per user. It would be incredibly wasteful, but you can do it until your server falls over with out of memory exceptions or you saturate the DB with connections.
>
> The main reason there’s a single connection and a global lock is to permit snapshotting. This snapshot cache is central to Apple’s ORM design. AFAIK, if you open 12 connections to the db, you’re still going to be stuck waiting on synchronized access to the one true snapshot cache. So you might as well have one connection and not waste the resource.
>
> The reason the Wonder pool leaks is because it tries to keep snapshots between the different OSCs synchronized. It tries to have the cake and eat it too. It does it by trying to rebroadcast NSNotifications to other stores, to update all the snapshot caches. But it fails to release the snapshots on those OSCs. So if you have 4 OSCs, EC brings the snapshot into one OSC, then the pool broadcasts it out to three more. When the EO for that snapshot is no longer needed, EC cleans it up, but the other three OSCs are left hanging onto the snapshots. There wasn’t really a fix that I could see outside of updating EOEditingContext when I found that leak… and even if you could, you’re still back to synchronized access on a hash map with multiple idle connections open waiting on that. Except now, you’ve got 4 hash maps and you have to wait idle while you try to write the same snapshots to all of them.
>
>
>> Or should I really be using another application framework?
>
>
> Probably. WO is dead. The main problem people here have is WO is very good at what it does. It is purpose built for the task, and most of us have yet to find anything we feel is a suitable replacement. A secondary issue is we all have lots of big applications to maintain in WO. Even moving to another Java based technology is going to be essentially a rewrite.
>
> If you’re writing a new app and you have something you like even a little bit better than WO, then use that. If you really like WO and you’re a glutton for punishment, then proceed with it :)
That’s why we have the Cayenne presentation at WOWODC.
>
>>
>> Tarun
>>
>>
>>
>>> On Jun 6, 2016, at 11:48 AM, Chuck Hill <email@hidden> wrote:
>>>
>>> I am pretty sure that maps to the ServerSocket’s backlog: “requested maximum length of the queue of incoming connections”
>>>
>>>
>>> From: <webobjects-dev-bounces+chill=email@hidden> on behalf of Ramsey Gurley <email@hidden>
>>> Date: Monday, June 6, 2016 at 10:44 AM
>>> To: Leigh Kivenko <email@hidden>
>>> Cc: WebObjects-Dev <email@hidden>
>>> Subject: Re: Question about jdbc connection pool
>>>
>>> Off the top of my head, not sure. It’s probably specified in java monitor help. But it has nothing to do with database connections AFAIK.
>>>
>>> On Jun 6, 2016, at 10:31 AM, Leigh Kivenko <email@hidden> wrote:
>>>
>>>
>>> Thanks again. What is the “Connection pool size” in the JavaMonitor then? Something else?
>>>
>>> <image001.jpg>
>>>
>>> Leigh Kivenko | VP, Technology
>>> PortfolioAid
>>> t. 416-479-0523 | e. email@hidden
>>>
>>> This e-mail may be privileged and confidential. If you received this e-mail in error, please do not use, copy or distribute it, but advise me immediately (by return e-mail or otherwise), and delete the e-mail.
>>>
>>> From: Ramsey Gurley [mailto:email@hidden]
>>> Sent: Monday, June 06, 2016 12:52 PM
>>> To: Leigh Kivenko <email@hidden>
>>> Cc: email@hidden
>>> Subject: Re: Question about jdbc connection pool
>>>
>>> Yes, one connection per application instance is the default.
>>>
>>> On Jun 6, 2016, at 9:47 AM, Leigh Kivenko <email@hidden> wrote:
>>>
>>>
>>>
>>> Thanks Ramsey. Does that mean there is only 1 database connection shared by all end-users of an app? So if a user hits a query that runs for 3+ seconds all other application users are stuck waiting for that query to complete?
>>>
>>> Leigh Kivenko | VP, Technology
>>> PortfolioAid
>>> t. 416-479-0523 | e. email@hidden
>>>
>>> This e-mail may be privileged and confidential. If you received this e-mail in error, please do not use, copy or distribute it, but advise me immediately (by return e-mail or otherwise), and delete the e-mail.
>>>
>>> From: webobjects-dev-bounces+dev=email@hidden [mailto:webobjects-dev-bounces+dev=email@hidden] On Behalf Of Ramsey Gurley
>>> Sent: Monday, June 06, 2016 12:18 PM
>>> To: Leigh Kivenko <email@hidden>
>>> Cc: email@hidden
>>> Subject: Re: Question about jdbc connection pool
>>>
>>> The ObjectStoreCoordinator opens one connection which everything shares by default. If you want multiple connections, you have to create multiple OSCs. There’s an OSC pool built into Wonder, but it leaks memory.
>>>
>>> On Jun 6, 2016, at 8:40 AM, Leigh Kivenko <email@hidden> wrote:
>>>
>>>
>>>
>>>
>>> Hello,
>>> How does one set the jdbc connection pool size? Is there a default if this isn’t specifically set?
>>>
>>> Thanks,
>>>
>>> Leigh Kivenko | VP, Technology
>>> PortfolioAid
>>> t. 416-479-0523 | e. email@hidden
>>>
>>> This e-mail may be privileged and confidential. If you received this e-mail in error, please do not use, copy or distribute it, but advise me immediately (by return e-mail or otherwise), and delete the e-mail.
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden