Re: Webobjects-dev Digest, Vol 5, Issue 1141
Re: Webobjects-dev Digest, Vol 5, Issue 1141
- Subject: Re: Webobjects-dev Digest, Vol 5, Issue 1141
- From: "dododo2020 dododo2020" <email@hidden>
- Date: Fri, 28 Nov 2008 01:20:48 +0900
Hello,
This is just a reporting about my approach.
1) I have decided to migrate my EOF projects into a plain generated JDBCEditingContext approach.
2) I picked sql2java not hibernate for replacement. And I could use the output from sql2java as a input for another generator.
3) I will investigate the DB layer enhancement with terracotta. Because my projects require massive realtime data stream.
4) I have suceeded in developing and deploying with intelliJ and projectbuilder without plugins and existing libraries.
5) I think I can continue to develop with WO even after Apple stoped its support.(I don't want to extend its death but want to live with WO.)
JDBCEditingContext is very plain and lockable with basic synchronized statements.
I hope I can be released from any problems coming from the frameworks.
I might think that the single threading of WO may be a result of framework's consistency.
I don't want to use it anymore or don't want to manage to use it as multi-threading with sacrificing something.
I may have mist-understanding or non-understanding somewhere but I feel contented with my simple approach.
Now it works without any problems and with massive scaling out.
WO is a mature product.
But mature is a before-death from a point of marketing.
I don't feel comfortable with extending death but feel comfortable with working out.
In the future I may summarize the solution.
Thank you.
Best regards,
Ken
> Don't you think terracotta's approach can enhance WO significantly
> with or without EO?
Without EOF .... possibly. With EOF, it's a very complicated problem
because EOF is single-lock on an object store. The contention point
in most WO apps is going to be your EOF lock, so clustering that lock
is only going to INCREASE contention. The typical WO scaling approach
is multiple instance, though as you see, this presents cache sync
issues (which is why ERJGroups exists).
> I think Tools of WO and structures are still the best but EO is not
> the best today.
I think it is just different. It's difficult to flat out say it's not
the best. You're pretty much going to be comparing against Hibernate,
I think. Hibernate doesn't do in-memory transactions, which I find to
be incredibly powerful. Hibernate, though, supports a richer caching
system which supports a distributed cache and has some SQL
optimizations that EOF doesn't. It doesn't do snapshot caches in
quite the same way, and most people don't really do multi-request
transactions with Hibernate. I'm not necessarily convinced that a WO
+ Hibernate app is a bad idea, just a very different programming
model. You should just be aware of what you're giving up making that
decision.
> I think EO's approach is delaying to the latest.
> I don't want to use additional mechanism or lock-unlock management
> just to increase instances or multiple requests.
> If Apple don't replace it and I don't have enough time to learn
> wonder I have to replace EO with something.
This is why I use Wonder ... It basically automatically solves most of
these complaints.
> I think
> 1) Having caches for each instance is not efficient. Sharing cache
> is the best.
This is VERY application-dependent. It makes some aspects of
development easier and some harder. If you have a large amount of
user-specific data, sharing a cache is just a good way to blow out
your cache. If you have very collaborative data, then a central cache
would probably be better. But shared caches aren't free ... The more
people you have using your cache, the more you are going to have to
lock, and if you're not locking, then you have to deal with the
fallout of not having a safe transaction model (unless you're using a
cache that is safely hooking into your overall transaction system and
does something like mvcc).
> 2) Developers today have to learn many things so learning vendor-
> closed technology is not for everyone.
I would agree with this ..
> 3) EOF may use String and Hashtable for many internal processes.This
> may slow the app.
I'm not sure what you mean about this one, but maybe you mean as
opposed to storing persistent object state in the fields of the pojo?
I think you'll find that if you profile your app, it's hitting your
database that is slow by a huge margin. Switching from state-in-maps
vs state-in-fields is likely not really near the top of the list.
So, really I don't think you're wrong, you just have to accept that
there aren't many people doing things like you are talking about
taking on, so you need to weigh that risk. But as long as you're OK
with that, I don't really see any terrible problems waiting for you.
I've considered making a WO + Hibernate app just to try it out, also.
_______________________________________________
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