|
| Re: CDO as an enterprise persistence solution??? [message #427674 is a reply to message #427673] |
Wed, 25 February 2009 16:47   |
 Simon Mc Duff
Messages: 596
Registered: July 2009 |
Senior Member |
|
|
hi Glenn,
Comments below
Glenn Silverman wrote:
> Is CDO a real enterprise persistence solution, ala, JPA? How scalable is
> it?
I will say people have different opinion on that question. So it will be
my personal opinion I will gave you.
First we used CDO for 1 year and an half in my enterprise and I used it to
build applications to my clients. We can handle billions of objects and we
have 25-30 users at the same time using it. We are very happy with it.
The word enterprise for me means... Running multiple CDO-Server, Out of
the box Failing strategy that will connect to others CDO-Server, tools to
debug, and more...
and CDO doesn't have all that at the moment. But we are going there!
>As I understand it, the CDO server has a single, always open
> connection to the data store, so there is no need for connection pooling.
It depends of the implementation. I prefer to say .. it will try to
minimize the connection to the db server.
> But CDO sessions is another matter. Sessions can remain open for long
> periods of time and it seems that some sort of session management by the
> client is needed if your applications are to scale.
One client can (should also) use only one session. From that session you
can open multiple CDOView/CDOTransaction.
> So, doesn't CDO merely shift the burden from connection management to
> session management? And wouldn't we be better off converting our EClasses
> to JPA annotated POJOs directly and simply using a tried-and-true JPA
> solution?
I will says depends of your requirements, if you don't need what EMF or
CDO brings you... I will say you don't need it.
> Any thoughts on this matter would be appreciated, particularly from
> someone who is using it in an enterprise. I'm simply trying to determine
> if an investment in time in a CDO solution is appropriate.
Personnally I used EMF to have a clear model that I can share, generations
of codes and I can be flexible enough to be able to have many differents
databases where objects are referring to each others transparently...
I liked CDO for many features that it is currently supported
(Notifications , locking, ...!!)... and the one that will come. (Support
Offline is a big one).
(new feature in 2.0 http://wiki.eclipse.org/New_And_Noteworthy_for_CDO_2.0)
But If your application doesn't need anything that EMF can bring you...at
the moment or in the future.... don't use it!
Simon
|
|
|
| Re: CDO as an enterprise persistence solution??? [message #427675 is a reply to message #427673] |
Wed, 25 February 2009 17:18 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Hi,
My 2 cents on this are:
a) Direct JPA usage in clients means 2-tier and so all your users have
physical access to your Database :-(
b) JPA in a 3-tier setup is not as easy as people tend do think because
lazy-loading is a concept not working smoothly when serializing
In a reply on another Use-Group I asked the following questions which
might help you decide if you really need EMF + CDO or maybe EMF + Teneo:
a) Concurrency: How to keep Objects up-to-date on multiple clients
b) Undo/Redo: How do you give users structural undo/redo support
c) Memory-Management: How do you ensure that your model fits into your
memory?
d) Do you need lazy-loading in a 3-tier application?
e) Do you want to access the database with CDO e.g. to create reports
using e.g. Birt, ...
a+b+c+d+e: EMF + CDO + Teneo / EMF + CDO
a+b+c+d: EMF + CDO
b: EMF
-: Use JPA directly :-)
I don't fully get what you mean with Session-Management because you
don't need to manage a session you simply open it and your object graph
is synced automagically by CDO.
Tom
Glenn Silverman schrieb:
> Is CDO a real enterprise persistence solution, ala, JPA? How scalable is
> it? As I understand it, the CDO server has a single, always open
> connection to the data store, so there is no need for connection
> pooling. But CDO sessions is another matter. Sessions can remain open
> for long periods of time and it seems that some sort of session
> management by the client is needed if your applications are to scale.
>
> So, doesn't CDO merely shift the burden from connection management to
> session management? And wouldn't we be better off converting our
> EClasses to JPA annotated POJOs directly and simply using a
> tried-and-true JPA solution?
>
> Any thoughts on this matter would be appreciated, particularly from
> someone who is using it in an enterprise. I'm simply trying to determine
> if an investment in time in a CDO solution is appropriate.
>
>
>
--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------
|
|
|
|
| Re: EMF + CDO versus EclipseUML + JPA [message #427819 is a reply to message #427769] |
Mon, 02 March 2009 12:46 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Vlad,
Comments below.
Vlad Varnica wrote:
> An important point to consider is what is the team previous
> experiences. I mean that if your team knows EMF then it is a good idea
> to start with EMF + CDO or Teneo. Don't forget that your need at least
> 6 month
You have empirical studies to back up this number? :-P
> to start with EMF if no expert in your team, and this should be
> considered as a long term investment.
And a good one too. Don't forget there are plenty of people available,
including me, to help teams get up to speed quickly with training,
coaching, and consulting.
> btw, this technological investment is a very profitable investment in
> your team and company technological assets.
That's often what people forget. The path of least resistance is all
too often one that involves shortcuts that need to be reconsidered
longer term.
>
> If your team doesn't know EMF then it is a lot simpler to immediately
> start with a traditional JPA tool.
I hold simplicity to be like beauty: in the eye of the beholder. Simple
is good when you start, but powerful is what keeps you going.
Consider when you need to build a UI around your data model. Suddenly
you'll be faced with a difficult problem, implementing a model view
contoller, that more difficult because of the choice to start simple.
I.e., you'll find notifications turn out to be quite important.
> I would then recommend EclipseUML (for modeling) + JPA (hibernate,
> Dali project etc...). The JPA annotations are live synchronized
> between the code and the model. Model and JPA are used at the same
> time but each one is independent even if synchronized.
If I understand correctly, JPA annotations can be maintained separate
from the code with little need for synchronization. I think the Teneo
EclipseLink integration will prove interesting. I'm looking forward to
the EclipseCon talk about it.
> Vlad
> Omondo
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
|
|
|
|
|
|
|
| Re: EMF + CDO versus EclipseUML + JPA [message #427881 is a reply to message #427880] |
Tue, 03 March 2009 17:19 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Vlad,
Comments below.
Vlad Varnica wrote:
> Hi Ed,
>
> I agree my message is a kind of advertisement but I am paid for that :-)
People pay me for consulting services yet when was the last time I
advertised on that on this newsgroup? When was the first time for that
matter?
> Sorry if it is too much.
You're laying it on a little thick in my opinion.
>
> Concerning your answer:
> 1. Did you know that Teneo supports EAnnotations right on the Ecore
> model itself? No, I didn't but is-it really important ? We are talking
> about JPA support and not eannotation in the model itself. We can add
> any kind of eannotations for example we use this eannotation to save
> the traceability in order to know in which diagram is saved a model
> element.
You kept circling around the point of model synchronization but given
that the necessary annotations are right on/in the model, there is
nothing to synchronize.
> For Omondo what is important is the JPA annotation in the code and not
> the eannotation in the model itself.
So what's the important point about synchronizing everything?
> btw, the question is what are the best pratices:
The question or a question?
> Is-it to save JPA annotation as stereotype in the UML model or to save
> it as Eannotation in the EMF model ?
Sounds functionally equivalent to me.
> Stereotypes inside UML are official OMG specifications therefore we
> think it is better to use stereotypes for JPA than Eannotation.
And therefore UML is better than EMOF, and therefore everyone should buy
EclipseUML and not simply Ecore. Nice assertions, but ones which which I
don't agree.
>
> 2. You seem to be assuming a lot less iteration in EMF that is
> actually there.
> EMF out of box (e.g. without the Omondo merge) is only using a top
> down approach. I mean from model to annotated code.
It's simply not true. You seem to have overlooked annotated Java as one
of the model input forms.
> This means that if the project change and that developers change
> manually the application at code level and not model level then it is
> not possible to get a model anymore.
They can change either level directly in the code, so again, simply not
true.
> I fully agree that both EMF + CDO or Eclipse+ JPA tools for JPA
> modeling are possible. For EMF all modification should be done at
> model level and for Omondo we think that modification can be made at
> model and also code level.
To me life's just not as black and white as you paint it.
> This is why we consider that in order to use an agile iterative
> approach it is better to directly work at JPA annotation level which
> are saved in the code and let JPA tools such as Hibernate do their job.
And of course all the while you simply don't answer Tom's questions.
>
> 3. And yet still you don't seem to have answered Tom's question. The
> answer is that UML live code and model synchronization is not related
> to Tom's question. He should ask the question on the JPA forum and not
> to me.
You seem to assume that nothing else EMF's generated code provides will
have interesting and useful value. Doesn't it seem likely someone will
want to build a UI around their data? Perhaps define a textual syntax
or a graphical syntax? Perhaps exchange their data using an XML
serialization. Build RESTful services around it... Anyway, I don't see
that this discussion will get us anywhere given that anything short of
doing things exactly the Omondo way will not be a best practice.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
| Re: EMF + CDO versus EclipseUML + JPA [message #427883 is a reply to message #427882] |
Wed, 04 March 2009 01:07 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Vlad,
Comments below.
Vlad Varnica wrote:
> Ed,
>
> I am not an EMF expert and I always recommend to use UML because this
> is a simple
UML and "simple" are usually not used in the same sentence.
> and common language for almost all the modeling community.
One might argue that (E)MOF is also common (t's used to define UML) and
it's certainly easier to argue it's simple.
>
> I can not also decide which is the better technology between using
> EMF+CDO or EclipseUML + JPA.
We're all entitled to our opinions. I'd characterize it as
EMF+Teneo+EclipseLink, but certainly CDO fits well into that picture too.
> We have selected to work within JPA tools providing UML editor because
> the market is bigger than just targeting EMF niche market.
Niche hey? Time will tell....
> I am also convinced that whatever is the quality of all related EMF
> projects working directly (e.g. no code generation from model) with a
> JPA tools such as Hibernate is the best solution.
Yet Teneo also works directly with Hibernate. It;s like the best of of
two bests...
> Good luck for your project. It seems to be very promising.
I'm not a big believer in luck. Good planning generally rules the day...
>
> Vlad
> Omondo
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.04659 seconds
] 
Search
Help
Register
Login
Home
