> Le 6 juin 2016 à 20:04, Ramsey Gurley <[email protected]> a écrit : > > On Jun 6, 2016, at 4:21 PM, Tarun Reddy <[email protected]> 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 protected]> wrote: >>> >>> I am pretty sure that maps to the ServerSocket’s backlog: “requested >>> maximum length of the queue of incoming connections” >>> >>> >>> From: <[email protected]> on >>> behalf of Ramsey Gurley <[email protected]> >>> Date: Monday, June 6, 2016 at 10:44 AM >>> To: Leigh Kivenko <[email protected]> >>> Cc: WebObjects-Dev <[email protected]> >>> 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 protected]> 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 protected] >>> >>> 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 protected]] >>> Sent: Monday, June 06, 2016 12:52 PM >>> To: Leigh Kivenko <[email protected]> >>> Cc: [email protected] >>> 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 protected]> 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 protected] >>> >>> 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: [email protected] >>> [mailto:[email protected]] On >>> Behalf Of Ramsey Gurley >>> Sent: Monday, June 06, 2016 12:18 PM >>> To: Leigh Kivenko <[email protected]> >>> Cc: [email protected] >>> 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 protected]> 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 protected] >>> >>> 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 protected]) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/webobjects-dev/rgurley%40smarthealth.com >>> >>> This email sent to [email protected] >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list ([email protected]) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/webobjects-dev/tvr1%40cornell.edu >>> >>> This email sent to [email protected] >> > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/probert%40macti.ca > > This email sent to [email protected] _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
