• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Question about jdbc connection pool
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Question about jdbc connection pool


  • Subject: Re: Question about jdbc connection pool
  • From: Musall Maik <email@hidden>
  • Date: Tue, 07 Jun 2016 10:52:27 +0200

> Am 07.06.2016 um 02:04 schrieb Ramsey Gurley <email@hidden>:
>
> 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.
>

Best summary of this I've read in a long time, thank you.

However, map implementations have made progress in recent years. java.util.HashMap performs quite well in Java 8 even with several million entries, and even if the key hashcode uniqueness is suboptimal (EO hashcodes are only 85-95% unique in my real-world measurements). I've already gained huge performance improvements by swapping NSMutableDictionary for java.util.HashMap in the snapshot cache (see ERXDatabase implementation). And there are more advanced concepts like copy-on-write that allow for minimal lags in concurrent access.

I'm eager to learn the details at WOWODC how Cayenne has solved this.

Maik
 _______________________________________________
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


References: 
 >Question about jdbc connection pool (From: Leigh Kivenko <email@hidden>)
 >Re: Question about jdbc connection pool (From: Ramsey Gurley <email@hidden>)
 >RE: Question about jdbc connection pool (From: Leigh Kivenko <email@hidden>)
 >Re: Question about jdbc connection pool (From: Ramsey Gurley <email@hidden>)
 >Re: Question about jdbc connection pool (From: Ramsey Gurley <email@hidden>)
 >Re: Question about jdbc connection pool (From: Chuck Hill <email@hidden>)
 >Re: Question about jdbc connection pool (From: Tarun Reddy <email@hidden>)
 >Re: Question about jdbc connection pool (From: Ramsey Gurley <email@hidden>)

  • Prev by Date: Re: How to avoid expensive fetches in database when setting to-one-relationship
  • Next by Date: Streaming of WOWODC 2016
  • Previous by thread: Re: Question about jdbc connection pool
  • Next by thread: Re: Question about jdbc connection pool
  • Index(es):
    • Date
    • Thread