Hi all ,

I am right now hosting my pages using jsp / servlet / hibernate on lunarpages. However, the admin inform me lately that it is not permitted to run hibernate on the platform because hibernate eat quite some memory.

So I am posting here to see :

1) is there any other web hosting company you know does not support hibernate.
2) is there any recommended web hosting company support jsp / servlet ?

Thanks.

Perseus

Just for my/our information - do you have any idea why then don't permit the usage of Hibernate ? It's a Java library like any other...

It's briefly about big memory usage of hibernate.

Please see
http://www.lunarforums.com/forum/viewtopic.php?t=9083&start=0&postdays=0&postorder=asc&highlight=hibernate

Hmmm... sure I can write a very small application that will consume all their memory - without HIbernate.
So I don't think refusing Hibernate is a solution to their problem :-(

Hmmmm interesting. I admit that Hibernate is optimized more for high throughput than for minimal memory consumption. There are tradeoffs here. It certainly is easy to make Hibernate eat memory if you have big datasets and big second-level cache.

But if you disable the second-level cache, use the single-session per request model, and use lazy fetching properly, I would not expect Hibernate to consume that much more memory than direct JDBC. The JDBC drivers themselves spew garbage....

I think its more likely that the kind of application that uses Hibernate tends, by nature, to eat more memory than simple JSP-page-to-direct-JDBC type applications. So these guys are observing "Hibernate" applications to be more memory intensive than other hosted applications and perhaps err in their causal inference.

Hello Hibernators,

I recently discovered myself in the same situation regarding
Lunarpages and their ban on Hibernate. One of their administrators,
Kelvin, writes:

> I understand the urge to use Hibernate, but this policy will not
> change (at least for our shared JVM hosting). The truth is,
> Libraries such as Hibernate and the applications that use them are
> simply too bulky for a shared JVM. Hibernate is targetted and
> developed for large scale J2EE applications, and its important to
> recognise that we don't offer this level of hosting - We only
> provide basic Jsp/Servlet support (else it would say J2EE on hosting
> plans) which is suitable for entry and small level applications.

> I've been a Java developer for more than 4 years, and in this time
> there has been very little effort by Sun or 3rd party library
> developers to address the imbalance of support for shared hosting
> and their requirements/limitations are completely overlooked.

> A typical example of this is memory allocation; Our servers can be
> equiped with upto 12Gb of RAM, but a JVM is only capable of handling
> a max 1.8Gb (approx) - if this limitation was resolved then the
> usage of larger libraries wouldn't be such an issue.

Is there anyone on the Hibernate team that can respond to these
concerns better than me? Actually, I'm sure there is!

The question really is, would you be willing to put in the cycles to
help resolve this so that web hosting companies, such as Lunarpages,
might look more fondly upon Hibernate?

Thanks to all for your good will, and efforts to communicate.

William BC Crandall
bc.crandall [around] earthlink.net

Hibernate scales up and down, it depends how you use it. Hibernate is not "bulky", it just has many features and is not as trivial to learn as Struts. He might have got something wrong by saying "many features, complex stuff" equals "needs lots of resources". This is not correct.

Good luck :)

I think Gavin hits it right on the head - the types of applications that use Hibernate may be more memory intensive (especially if you use an agressive second-level cache) than the typical, small everything-in-JSP or lightweight Struts app. Have you considered using a Virtual Private Server instead? You get your own JVM and memory allocation that way. I've been reasonably happy with JCentric, and they don't squawk about my periodic memory spikes (I *do* use an agressive 2nd-level cache with a 2-minute time-to-live).

Scott

Hello Christian and Scott,

Thanks for your thoughts and suggestion. A last comment from Kelvin:



At this point, I leave it to you folks to consider if this is a viable
or attractive way to move Hibernate forward.

For myself, I'll focus on developing my application, and may well end
up at JCentric. Thanks for the pointer, Scott. This may be a case of
"you get what you pay for," and the market is competitively aware.
But there seems some room here. JCentric looks nice, but is 4x the
cost of Lunarpages. Is there a known community of Hibernate-friendly
hosting services? And might some/one of them cost less than $450/year?

Thanks again for the thing itself (I'm enjoying my Hibernate learning
curve), and for any additional pointers.

All the best,

William BC Crandall
bc.crandall [around] earthlink.net

Well, its difficult to guess at what kind of changes we could make that would change their policy. I mean, you can always install Hibernate without some of its dependant jars (for example the cache provider jars). But I don't really see much bloat in the core that I could really just strip out.

I'd have to understand the problem MUCH better.

If it is the size of Hibernate itself, latest version of jars is 1087k hibernate3.jar + 984k minimal dependencies, though I'm not sure how that translates to memory consumption at runtime.

If its the size of the cache well, you can't run a cache without the cache provider jars.

Well, I can see Kelvin's perspective, though he should note that 2nd-level caching is already disabled by default - you have to add the jars, reference them in the Hibernate config, configure the caching library (i.e. ehcache.xml) and define your objects as cachable in the mapping documents before Hibernate makes use of it. As such, I doubt there's a need to produce a "slimmed-down" package.

Perhaps he could change his policy to restrict maximum memory usage per application, regardless of the source. I say this because Hibernate isn't the only way to fill up a server's memory. Stuffing lots of display object into the HttpSesion can do it, buggy raw JDBC code which leaves Connections open can do it (one of the reasons why I prefer Hibernate) and the poor use of Singletons and Servlets can leak resources as well.

Another thing to consider is that even if a developer is making judicious use of caching (i.e. not as aggressive as I can get away with on a VPS or dedicated JVM), they're imposing a *much* lower load on the backing database server's memory and CPU allocation, and this is frequently on the same box anyway...

Scott

This is not a problem.
If you use Apache web server then you can use a many tomcat instances as you want. Use Proxy server and JVM per aplication (or a few JVM's per application), it is very trivial to setup this infrastructure (I am not admin, but I can do it myself). It is more secure and "safe".

I use this way to deploy my applications, I do not have hosting problems, but I have more reasons to deploy my stuff this way.

Another constraint is the system accesses that Hibernate seems to require.
My ISP refuses to set the Security Manager permissions required by Hibernate:

http://www.hibernate.org/294.html

Why, are you trying to run a Hibernate app in a shared JVM?

Scott

Yes.