Re: Hibernate
Re: Hibernate
- Subject: Re: Hibernate
- From: Karthik N <email@hidden>
- Date: Wed, 25 Feb 2009 10:09:48 -0800
Inline ...
1. the Session doesn't need to be tightly bound. unlike EOEditingContext that's tightly bound to the EOObjectStoreCoordinator
I'm not exactly sure what you mean here, or what you the desired features would be if you could "unbind" an EC from an OSC? You can obviously just make an EC with a new instance of an OSC and have it standalone, but I'd be curious to hear more about what kinds of problems you're trying to solve.
For request-response loop 1, I could have Session bound to DB connection 1, and for request-response loop 2 I could have the same Session bound to DB Connection 2. As I understand EOEditingContexts are bound to an OSC. So all the ECs for one OSC would contend for the same DB connection and it would be harder to scale out?
2. it's easier to multi-thread and connection pool with Hibernate
I'm not sure this is NECESSARILY true ... I suppose it depends on how you look at it, but for instance, http://blog.xebia.com/2009/02/07/hibernate-and-multi-threading/ basically shows that Hibernate has some of the same threading complexities that EOF does with respect to sharing objects between threads, at which point, you're really probably comparing using multiple OSC's. I will definitely grant that EOF's snapshot cache is both a blessing an a curse. I believe hibernate has a "snapshot cache" (equivalent) as well, but that the default behavior is that the cache goes away when the session goes away (which is typically session-per-request in Hibernate as I understand it?), so there are much fewer issues with cache freshness in exchange for default behavior that hits the db more often. You can add a second level cache to Hibernate, at which point, I imagine the issues are identical (cache invalidation is cache invalidation -- no way around it really). Hibernate is written with much better abstractions here, though, in that you can rip out the backing layers and change their behavior -- this is very hard to do in EOF, though something that will hopefully be changed. I think one of the issues with WO/EOF is that it's easy to do some really complicated things, but actually kind of hard to do some easy things ... If you WANT to make an app that has the behavioral characteristics of, say, Rails w/ routers and controllers + EOF that behaves more like Hibernate or ActiveRecord, you really have to work at it. I'd like to see some more support for alternative use cases -- I sometimes feel like I'm fighting EOF to do something that shouldn't be hard.
Kind of similar to #1 above. It's easier to just take a free connection from a DB connection pool. In essence a Hibernate session directly binds to a DB connection and doesn't have an OSC layer in between.
Yes, Hibernate has the same multi-threading challenges that EOF does, [like the Session is not thread-safe]
_______________________________________________
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