6 ms·

Masochism and Hibernate go together like peanut butter and jelly

stickfigure 14y ago
Thanks to Hibernate's second level caching, Kink.com's entire user-facing website traffic could be served by a single appserver and single MySQL instance.* Try that with Ruby. * Not including NATS, which is an abomination.
- jaggederest 14y ago
  Have done, thanks, varnish is the answer.
  - stickfigure 14y ago
    Unless you serve personalized pages. Which Kink does.
    - moe 14y ago
      A small bit of javascript tends to help with that.
      - stickfigure 14y ago
        That doesn't solve the problem at all, it just moves it from the generate-HTML request to a followon get-the-content-appropriate-to-this-user ajax request. Generating the information for each page is complicated, especially at Kink where your ability to interact with each "shoot" is determined by subscription rights, admin rights, microcurrency purchases, and who knows what else these days (I haven't seen the codebase in over four years). Hibernate's clustered 2nd-level cache is still pretty magical. It means that the vast majority of web page requests are serviced out of RAM with zero database hits - without writing any special caching code. And it's transactional. For a certain set of scaling problems, this feature is golden.
        moe 14y ago
        I've worked for a gaming site under the same constraints (probably stricter because real money was involved with nearly every transaction, no caching allowed). Hibernate caching can surely be helpful, but you make it sound like a silver bullet and like there's no other approaches. There are plenty without tying yourself to J2EE hell. A little bloom filtering with memcached or redis can work wonders and might be more predictable than an opaque caching layer that can make you very unhappy once your working set exceeds a "magical" threshold (been there, with hibernate).
        stickfigure 14y ago
        Oh, I don't claim it is a silver bullet. It can be frustrating as hell at times. And of course you can build your own distributed, transactional caching layer. My point is that once you end up with a certain level of sophistication and scaling, you create your own hell. Hibernate is fairly refined technology for dealing with this exact situation. Homebrewing your solution is like wandering around in the desert - if you're smart, you'll make it out, if not, you'll be the next Friendster. And FWIW, Java EE is not hell if you avoid the overengineered pieces like JSF.
        deleted 14y ago
        [deleted]

Thanks to Hibernate's second level caching, Kink.com's entire user-facing website traffic could be served by a single appserver and single MySQL instance.* Try that with Ruby. * Not including NATS, which is an abomination.

jaggederest 14y ago
Have done, thanks, varnish is the answer.
- stickfigure 14y ago
  Unless you serve personalized pages. Which Kink does.
  - moe 14y ago
    A small bit of javascript tends to help with that.
    - stickfigure 14y ago
      That doesn't solve the problem at all, it just moves it from the generate-HTML request to a followon get-the-content-appropriate-to-this-user ajax request. Generating the information for each page is complicated, especially at Kink where your ability to interact with each "shoot" is determined by subscription rights, admin rights, microcurrency purchases, and who knows what else these days (I haven't seen the codebase in over four years). Hibernate's clustered 2nd-level cache is still pretty magical. It means that the vast majority of web page requests are serviced out of RAM with zero database hits - without writing any special caching code. And it's transactional. For a certain set of scaling problems, this feature is golden.
      - moe 14y ago
        I've worked for a gaming site under the same constraints (probably stricter because real money was involved with nearly every transaction, no caching allowed). Hibernate caching can surely be helpful, but you make it sound like a silver bullet and like there's no other approaches. There are plenty without tying yourself to J2EE hell. A little bloom filtering with memcached or redis can work wonders and might be more predictable than an opaque caching layer that can make you very unhappy once your working set exceeds a "magical" threshold (been there, with hibernate).
        stickfigure 14y ago
        Oh, I don't claim it is a silver bullet. It can be frustrating as hell at times. And of course you can build your own distributed, transactional caching layer. My point is that once you end up with a certain level of sophistication and scaling, you create your own hell. Hibernate is fairly refined technology for dealing with this exact situation. Homebrewing your solution is like wandering around in the desert - if you're smart, you'll make it out, if not, you'll be the next Friendster. And FWIW, Java EE is not hell if you avoid the overengineered pieces like JSF.
        deleted 14y ago
        [deleted]