|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 35
Messages: 35
Messages: 35
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
WebLogic Server 10 Passes Java EE 5 CTS
BEA's WebLogic Server 10 Technology Preview is now certified against the Java EE 5 CTS. This is an important milestone on the pathway to the WebLogic Server 10 general availability release in March.
WebLogic Server 10 supports the full Java EE 5 specification, and includes strong Web Services interoperability capabilities.
This release introduces a new filtering classloading mechanism that lets developers use jar versions that conflict with classes used inside the server, and ships with Kodo 4.1 (and thus OpenJPA) as the default JPA persistence provider. WebLogic Server 10 also improves on the deployment capabilities of the server, such as the WLST recorder and improvements to side-by-side deployment. For a more comprehensive list of new features, see the release notes.
The upgrade from WebLogic 9.x should be straightforward. We have taken steps to ensure that the code paths of old component types (such as EJB2 beans) are largely unchanged, to minimize any potential upgrade surprises.
|
|
|
Message #227241
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Great!
Good to see that more and more organisations are about to release Java EE 5 servers. I think Java EE 5 is a major step forward, but adoption has been slow. Very few projects that I currently know of use the full Java EE 5 stack.
Of course the fact that there's no Websphere, WebLogic, JBoss, hence not even just something that implements the servlet & jsp specs + jsf spec (e.g. Tomcat 6 + Myfaces 1.2) in a stable release may have something to do with this...
We're not there yet, but it's getting close. Jboss AS 5 beta 1, Tomcat 6.09beta and now WebLogic 10 TP (of course, Glassfish doesn't count since the public opinion is to avoid using Sun software except for the JDK, right?)
|
|
|
Message #227244
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Great!
of course, Glassfish doesn't count since the public opinion is to avoid using Sun software except for the JDK, right?
wrong :)
|
|
|
Message #227260
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Great!
I'm happy to see that "Commercial world" seems to be more reactive than before. BEA seems to be as fast as JBoss, JOnAS or Tomcat for JEE 5 implementation.
I just hope that it's possible to use Hibernate instead of Kodo for JPA implementation.
|
|
|
Message #227261
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Great!
I just hope that it's possible to use Hibernate instead of Kodo for JPA implementation.
You can use Hibernate inside WebLogic, but it's not going to have tight integration.
For JPA, there is a pretty big performance delta between KODO and Hibernate as well, from what I've heard.
Peace,
Cameron Purdy
Tangosol Coherence: The Java Data Grid
|
|
|
Message #227263
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Great!
I just hope that it's possible to use Hibernate instead of Kodo for JPA implementation.
You can use Hibernate inside WebLogic, but it's not going to have tight integration.
For JPA, there is a pretty big performance delta between KODO and Hibernate as well, from what I've heard.
Peace,
Cameron Purdy
Tangosol Coherence: The Java Data Grid
You mean OpenJPA/Kodo performs better than Hibernate? or the contrary? It's an interesting issue...
Any non-biased comparison between JPA implementations out there?
|
|
|
Message #227266
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Perf
Any non-biased comparison between JPA implementations out there?
No, because "JPA performance" is simply a meaningless thing to talk about.
Are we interested in performance of simple CRUD (this is what is usually measured by "benchmarks"), or are we interested in performance of very complex operations that operate over large graphs of objects? Since simple CRUD is *never* a bottleneck in the performance of real applications (who ever heard of anyone ever in history having performance problems using Hibernate to do CRUD?), I would argue we care about the complex stuff, with complex association management. But how do you design a fair benchmark for that? Different products perform well in different complex cases.
Are we interested in performance against a local database (no caching) or a remote database (caching important)? Are we interested in performance in a cluster - where caching has a *totally* different performance profile?
Are we interested in performance in cases of extremely high concurrency, or cases where one thread is churning the database? Different products will respond differently.
For example, stuff like ActiveRecord or iBATIS will always be "faster" than stuff like Hibernate or Kodo for trivial CRUD operation against a local database. But start fetching deep object graphs into memory from a remote database in a clustered environment and ActiveRecord/iBATIS start to break.
So anytime you hear someone like Cameron saying "product X is faster than product Y", its simply nonsense - just like most stuff that comes out of Cameron's mouth where anything vaguely related to JBoss is concerned - unless they specify *for what*, *in what cases*, is it faster. Blanket statements only make sense in BEA marketing materials, not in the Real World.
|
|
|
Message #227267
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Perf
And by the way - I'm a bit out of date, but the actual measurements I did a year or so ago of simple CRUD performance of Hibernate vs. Kodo gave a mixed bag of results. They are slightly faster on creation/destruction of the persistence context and on inserts, we are a bit faster on queries. For mass operations on many objects, they are faster if you use standard APIs, we are quicker if you use StatelessSession. Etc.
Nowhere did I find anything that was a big enough difference that you would prefer one product over the other on the basis of performance alone.
Which confirmed to me that the BEA marketing line of the time that "Kodo is faster than Hibernate" is just the usual marketing BS, which was my initial reaction.
|
|
|
Message #227268
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Perf
So anytime you hear someone like Cameron saying "product X is faster than product Y", its simply nonsense - just like most stuff that comes out of Cameron's mouth where anything vaguely related to JBoss is concerned
Hmmm. I think he didnt actually say which way around it was. Have you had the Fleury insult "module" implanted, or was it always there ?
Blanket statements only make sense in BEA marketing materials, not in the Real World.
Or JBoss marketing materials for that matter. Or Oracle marketing materials. Or Tangosol marketing materials. Or Cocobase marketing materials.
|
|
|
Message #227271
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Comparison
You mean OpenJPA/Kodo performs better than Hibernate? or the contrary? [..] Any non-biased comparison between JPA implementations out there?
Considering the source, the information that I have is heavily biased. FWIW - the test results indicated that the OpenJPA-based implementation in the latest WebLogic (see the other TSS thread) was significantly ahead of Hibernate in terms of performance.
There is no standard benchmark yet for JPA that I am aware of, so you are currently left to mock your own up. PetStore in whatever latest incarnation is probably a decent start. Regarding these two products and their purported difference in performance, my guess is that the difference is largely related to a more efficient out-of-the-box caching implementation (note: no relation to our own Coherence product, which works with both OpenJPA and Hibernate).
Peace,
Cameron Purdy
Tangosol Coherence: The Java Data Grid
|
|
|
Message #227273
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Perf
So anytime you hear someone like Cameron saying "product X is faster than product Y", its simply nonsense - just like most stuff that comes out of Cameron's mouth where anything vaguely related to JBoss is concerned Hmmm. I think he didnt actually say which way around it was.
You're right - from the form of words used, it could be that Cameron was claiming that Hibernate is a lot faster than Kodo. If Cameron had a reputation for fair-mindedness on matters relating to JBoss, I would have taken his statement to be ambiguous. Perhaps I'm wrong, perhaps he was actually saying Hibernate is faster, and then I guess I look like a total ass. But knowing Cameron, I very much doubt that this is what he was saying ;-)
But the real point is that no matter which way round the statement was intended, it is still a nonsensical statement. Relative ORM performance is simply a much too complex topic to sum up as "X is faster than Y", without specifying for which scenarios.
"Benchmarks" and "performance tests" are a pet peeve of mine from wayback, actually.
http://hibernate.org/157.html
Blanket statements only make sense in BEA marketing materials, not in the Real World.
Or JBoss marketing materials for that matter. Or Oracle marketing materials. Or Tangosol marketing materials. Or Cocobase marketing materials.
Actually you won't find blanket statements about performance in JBoss marketing literature, nor will you find them in our public statements. Our position has always been that the only performance test that matters is a test of *your* application in *your* production environment. If you want to know how Hibernate and Kodo compare in terms of performance, try each of them out in some typical use cases in your application, under a typical production load. (My bet is that you will be real hard pressed to notice much difference at all, since the ORM is rarely the bottleneck.)
Notice that for JBoss vs. WebLogic, we have been through this process with a number of extremely high-scalability sites, who made the decision to switch to JBoss after seeing how JBoss performed compared to their existing WebLogic deployment.
That's why we don't do stuff like specj. Do you realize that the big vendors have teams of people working continuously trying to squeeze the last ounce of performance out of this totally synthetic benchmark? There is no way that tiny JBoss had the money to compete in that game (perhaps we do now, lets see what happens). And specj results simply don't translate to the real world. Specj tells you how fast an application server performs when running specj - as long as you have years and millions of dollars to spend on optimization. It tells you nothing at all about how the application server will run any real application in a slightly different deployment environment.
I'll stop ranting about that stuff now. It's a sore point. We've been putting up with performance FUD for years.
|
|
|
Message #227274
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Comparison
You mean OpenJPA/Kodo performs better than Hibernate? or the contrary? [..] Any non-biased comparison between JPA implementations out there?
Considering the source, the information that I have is heavily biased. FWIW - the test results indicated that the OpenJPA-based implementation in the latest WebLogic (see the other TSS thread) was significantly ahead of Hibernate in terms of performance.
There is no standard benchmark yet for JPA that I am aware of, so you are currently left to mock your own up. PetStore in whatever latest incarnation is probably a decent start. Regarding these two products and their purported difference in performance, my guess is that the difference is largely related to a more efficient out-of-the-box caching implementation (note: no relation to our own Coherence product, which works with both OpenJPA and Hibernate).
Peace,
Cameron Purdy
Tangosol Coherence: The Java Data Grid
Sorry, I typed my last post before seeing this.
Cameron, it would have been better, before repeating as fact statements that you read on TSS, to identify the source of those statememts (presumably BEA, in this case).
I can't comment about performance of Hibernate vs. Kodo in WebLogic, since I've never tried it.
Regarding out-of-the-box caching, Hibernate ships with caching turned off, and you have to do some tuning and configuration before you will get decent performance of the cache. We think that this is the right thing to do, for various reasons, even if it might make us look slow in some cases.
Petstore is a *terrible* test of ORM performance. It doesn't contain anything beyond trivial cases. This is exactly the problem I'm talking about.
|
|
|
Message #227275
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Comparison
Sorry, I typed my last post before seeing this.
Yeah, and I typed a whole response to you, which no longer seems fitting either ;-)
The person whom I spoke to was in the middle of a long series of performance tests, including comparisons among several ORMs. I haven't seen the tests themselves, so while I trust the source, I can't verify the tests or their results, and as I said, there is reason to acknowledge bias.
Bias does not itself invalidate the results; it simply suggests that one counts them initially as more suspect, and holds them to a stricter process of verification. You and I are obviously not the only ones without sufficient time to do all of these tests ourselves, and trust me, I'd love to have the time to look at the latest of all of the various ORMs out there and test them in detail. Sometimes, I feel like I'm stuck in 2005 when it comes to my knowledge of ORMs, because that's the last time that I had the time to look at them in detail.
Perhaps it's time to have an open source set of benchmarks, just like we have open source sets of solutions.
Peace,
Cameron Purdy
Tangosol Coherence: Shared Memory and Single System Image for Java
|
|
|
Message #227276
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Comparison
Bias does not itself invalidate the results; it simply suggests that one counts them initially as more suspect, and holds them to a stricter process of verification.
Actually it does. Never in history has a vendor paid for a benchmark that came out showing their product as slower than the competition. I have no doubt that this BEA-sponsored benchmark will show exactly the same thing as every vendor benchmark in history: namely that their product is faster.
If BEA *really* wanted to get a "fair" result, they would be calling up the Hibernate team and getting us involved in configuring our product, just like I'm sure they chose an optimal configuration of our product. Folks at BEA certainly know my email and cellphone number.
Since they have not tried to take this step, we can assume that "fairness" was not the goal.
|
|
|
Message #227278
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Comparison
Never in history has a vendor paid for a benchmark that came out showing their product as slower than the competition. Well we don't know that - they could have. I just doubt they'd publish the results of such a benchmark. :)
|
|
|
Message #227279
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Comparison
Perhaps it's time to have an open source set of benchmarks, just like we have open source sets of solutions.
An excellent idea.
|
|
|
Message #227282
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Great!
We're not there yet, but it's getting close. Jboss AS 5 beta 1, Tomcat 6.09beta and now WebLogic 10 TP (of course, Glassfish doesn't count since the public opinion is to avoid using Sun software except for the JDK, right?)
Sorry but I think you're wrong about Glassfish. I've been working with it for a couple of months and it performs much better than JBoss (Hibernate JPA) and as fast as OC4J (Toplink JPA). My company is considering Glassfish for replacing our production OC4J instances, due to its great performance running on the same environment (SuSe 9 - 10GB RAM clustered boxes). Also, IMHO, no ORM/JPA beats Toplink, which is one of the first and most stable ORM products and is the reference implementation of JPA.
Regards,
Gustavo
|
|
|
Message #227283
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: TopLink
Also, IMHO, no ORM/JPA beats Toplink, which is one of the first and most stable ORM products and is the reference implementation of JPA.
Whether what you say is true or not you provide no facts to back it up. PS: A "reference implementation" is by definition a "proof of concept". It is there to demonstrate that a specification is implementable, and nothing more. That doesn't imply better.
|
|
|
Message #227303
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: TopLink
Also, IMHO, no ORM/JPA beats Toplink, which is one of the first and most stable ORM products and is the reference implementation of JPA.
Whether what you say is true or not you provide no facts to back it up. PS: A "reference implementation" is by definition a "proof of concept". It is there to demonstrate that a specification is implementable, and nothing more. That doesn't imply better.
On the contrary, it usually means it's not a production ready product.
|
|
|
Message #227307
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Great!
Gustavo, the good news I take from your post is happiness with TopLink - both the reference implementation that Oracle provided as part of Glassfish and, in case you did not know, also ships with OC4J 10.1.3.1 (presumably why you are seeing equivalent performance between the two) but also its great to hear positive comments on the full fledged TopLink product line.
However, I can't say, being from Oracle and the Java platform group product management team, that the prospective switch out of OC4J for Glassfish is something I am keen to hear! If you have specific issues with OC4J, I would appreciate a note from you on issues you are facing and the version you are using - I can be reached at mike.lehmann@oracle.com.
Mike Lehmann, Oracle
Java Platform Group
Product Management
|
|
|
Message #227341
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
OC4J problems
Hi Mike,
Since you are asking for the issues with the OC4J, Here we go. I have helped a logistics company to stabilize their production 10.1.2 OC4J instance and eventually migrate their transportation management application from OC4J 10.1.2 to JBoss 4.0. This application has more than 1000 entity and session beans with JSP front-end were running on 6 OC4J instance with oracle HTTP server and supports more than 400 concurrent users.
The OC4J has lot of memory leaks and it slowly creep up the memory. We were force to restart the OC4J instances everyday. If you restart the OC4J you also have to restart the HTTP server to make the HTTP server connects to the OC4J
OC4J is very forgiving related to entity beans relationships and code generated from the Oracle JDeveloper generally won’t confirm to the J2EE spec and obliviously it won’t run in any other server.
The JSP pages generated using the JDeveloper does not close the tags properly and OC4J parse and run the files happily. Once we started to port the code over JBoss and it really made out life.
The Enterprise manager and management sever web interface is really flaky and it hang-up or time out frequently and after the hung-up we can’t manage the instances from shell prompt too. The management server frequently corrupts the management store or the some data store and then we need to rebuild the environment again from starch.
OC4J won’t run properly if the JVM has more than 1.6 GB ram (forget about the 64 bit VM) under Sparc-Solaris with sun JDK 1.4.2 and we were force to split our load with multiple instances.
The Mod OC4J or OC4J instance has a preset max connection limit as 100. If the connection exceeds more than 100 for an instance it arbitrarily time out client session and force the client to re-login to the application. This not documented anywhere.
The documentation in general nowhere close to any commercial application server and it also really hard to find things in the documentation set. There are some many patches and versions it is really hard to keep in track of all those things.
The oracle support for Application server is not up to the mark and anytime you call the support the standard answer is please update to the latest patch release. There is no assurance that the specific problem is fixed in the patch. We did update couple of time to the latest patch and after spending the weekend to update the machines to the latest patch level and the problem still persist what is the point of doing that again and again. We stop calling oracle support for help and we started to fix the process like restarting the application server/ management server everyday, splitting the load on multiple instance of OC4J, running OC4J in multiple machines, etc
The client also tries to use oracle consulting service to trouble shoot the application and the oracle recommendation was to upgrade to 10.1.3. I did some tests with the 10.1.3 and it look promising and lot better than the 10.1.2 but still there are lot of issues with the management server but at least the OC4J instance are lot better compare to the 10.1.2.
The another problem with the oracle application server is since it is from oracle the DBAs take the production support for the app server and they are not tuned to support the app server instances and don’t have any idea about Java language or JVM tuning or nature of servlets, EJB etc. It really made the development team life really hard.
Since the CPU utilization of the large Sparc Solaris boxes running the application server is very low due to the fact that OC4J does not scale well on large box with more memory. The infrastructure team decided to use dual CPU AMD Opteron servers with Solaris 10 for the application server instances. Since there is no oracle application server support for X86 Solaris and the problem with DBAs production support for the application servers and the numerous OC4J bugs forces the management and development team to move away from oracle for application server and port the application to JBoss. It is really a port because the code running on oracle application server is not complaint to J2EE spec and oracle is very lenient and forgiving on the spec and run any crappy JSP and EJBs happily.
Oracle application server suite has lot of unique ideas and features and it has or planning to have a tight integration between HTTP server, vanilla J2EE container, portals, Identity management, integration, ESB and BPEL engines, etc and the general direction for the management server with the latest diagnostic pack is really good. The main problem with oracle is the implementation of the idea and integration of various products as a single suite is not up to the mark and it is not yet ready as a quality commercial product. I kind of understand the over all oracle direction for the product and it is getting better by every release, hope you guys can get it right with the fusion release. If you guys ever make a fully integrated quality product with all the planned features it should be top notch really developer friendly application infrastructure platform for SOA.
There is also lot of bad experience with the previous versions of the oracle middleware products and I know lots of developers are really against the idea of using oracle for anything other than the database. I am sure this bad reputation and perception is going to hurt the future adoption of the product unless you guys really do something to change it.
Thanks,
Monickam
|
|
|
Message #227351
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Great!
We're not there yet, but it's getting close. Jboss AS 5 beta 1, Tomcat 6.09beta and now WebLogic 10 TP (of course, Glassfish doesn't count since the public opinion is to avoid using Sun software except for the JDK, right?)
Sorry but I think you're wrong about Glassfish.
Well, actually it isn't my opinion. That why I added the "right?" part at the end of my sentence. It seems to be the popular opinion of the serverside crowd though. I've been lurking this site for years and in most every news posting where something from Sun is discussed, many people feel they have to claim that everything Sun related (except for the JDK) is bad.
|
|
|
Message #227362
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
OC4J continued
Well, I did set myself up for this so here goes a response as some issues I believe are resolved in the current release (you mention this as well) and others may be issues in how the product was used ... I hope this does not hijack the thread too much though this is probably the more entertaininng for some. If others have similar feedback, my e-mail is also here - mike.lehmann@oracle.com. Monickam, do follow up for the open issues that I am not able to respond to here with your e-mail.
- Memory leaks. I see you logged TARs and then gave up. I can follow up and see what happened and see if it can be resurrected and resolved. We have a large number of mission critical customers running 24X7 on OAS - both 10.1.2 and 10.1.3 - that don't have that issue.
I don't dispute you have/continue to have issues there - 10.1.2 has had a number of patch sets - service packs in other product vernacular - as it has been out for several years now. Despite the pain you appear to have had with support, they truly are trying to help and those latest patchsets are meant to resolve these types of issues. In each patchset is a running commentary of the bugs fixed in the readme.
- JDeveloper code generation. I can't really speak on that team's behalf but can make some server side comments. Ironically, I would say the number 1 migration issue I get with customers moving from Jboss to OC4J is we are too strict with our interpretation of the servlet/JSP spec. I have running requests to relax our interpretation to Tomcat as per some of this sample doc here:
http://download-west.oracle.com/docs/cd/B32110_01/web.1013/b28959/develop.htm#CHDFJJDA
That doesn't help your issue with the code generation - I have heard the JDev JSP comment before and believe they invested to resolve that in JDev 10.1.3. I have not heard the EJB one before - there is a hugely active JDev forum on OTN where the development team is actively engaged that could help there. See:
http://forums.oracle.com/forums/forum.jspa?forumID=83
One thing that JDeveloper does strive very hard to do here is ensure portability of their applications produced to other app servers and supports WebLogic, Tomcat, JBoss above and beyond OC4J and I think by the marketing numbers they put out almost half their users use third party application servers too. I am puzzled by the comments on the EJB generation, less so on the JSP side as per my comments above.
- Enterprise Manager. I have to agree that the container management console in 10.1.2 was not the best on the market. This is why we did a complete rewrite of the console in 10.1.3 - ala what BEA did in 9 - and I think we hit the management concerns much stronger and more satisfactorily in that release. Again doesn't help you on 10.1.2 but hopefully some possibilities going forward.
- On mod_oc4j. I have not heard this one before - defaults are here:
http://download-west.oracle.com/docs/cd/B31017_01/web.1013/b28948/confmods.htm#CIHDBIDJ
This may be a 10.1.2 issue so have that as a takeaway to follow up on.
- On DBA's doing application server administration - yup. A common issue I see - sometimes they very effectively adapt sometimes they don't. This is a bit of the nature of the beast at Oracle as people unfortunately equate Oracle as one product when in fact it is quite a portfolio of products and like any other application server, a specific skill set is needed, just like being an apps administrator for Siebel or Peoplesoft is not the same as a DBA.
- On scaling OC4J and dealing with 32 bit JVM limits on heap size there are a fair number of things we have done there in both 10.1.2 and 10.1.3 that try to help that issue. It isn't always necessary to create a separate OC4J instance to scale - there is a feature that lets you configure an arbitary number of JVMs per instance to more fully use CPU resources rather than creating additional instances:
http://download-west.oracle.com/docs/cd/B32110_01/web.1013/b28950/topology.htm#BIHIBEHI
This has no configuration management overhead other than changing the number of JVMs so many people like it over creating independent instances.
We have customers running with 100's of OC4J instances managed as a single cluster using this strategy in conjunction with separate instances. Not sure you tried thi s but it is one of the most popular scaling approaches for OracleAS particularly with the JVM heap size you mention and people either not able to for various reasons to go to 64 bit JVMs (be it product certification or in house reasons).
It may not be comfort to you now, but there is an X86 Solaris 10.1.2 release available now though, granted, we have not finished the cert on 10.1.3.x yet:
http://www.oracle.com/technology/software/products/ias/htdocs/101202.html
In terms of the future, we think that OracleAS 10.1.3 is strong foot forward in terms of addressing a number of your 10.1.2 concerns thus the commentary from consulting and others to go to 10.1.3. It is not only what the rest of the Fusion Middleware stack uses out of the box, it is what Peoplesoft, Retek, Siebel, iFlex, JDE and others have and are certifying their ERP/CRM stacks on. By no means - like any product - is it perfect but based on the adoption we continue to see and the feedback we have had it is a substantial improvement from past releases.
Please do follow up with me offline if you would like to discuss further.
Mike.
mike.lehmann@oracle.com
|
|
|
Message #227364
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: TopLink
On the contrary, it usually means it's not a production ready product.
For what it's worth, we've been using Glassfish (which means the JSF RI as well) for almost a year now with really good success. They may both be reference impls, but it has been our experience that any preconceived notions concerning reference impls just don't apply here.
|
|
|
Message #227365
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Perf
Gavin,
Would it be possible to provide some more information about the measurements you did? Specifically:
1. What versions of Kodo and Hibernate was used?
2. What hardware/JVM/OS/db was used?
3. Was it ensured that no other piece of the system - i/o, db - was a bottleneck?
4. What was the standard API that was compared - JDO or JPA?
5. Were the measurements taken with multi-threaded access?
6. Would you happen to remember what kind of response-time or throughput you got with Kodo?
A couple of lines about the use-cases measured would be nice too, if you have the time to put it in and it's not a problem.
Thanks!
Arunabh
|
|
|
Message #227367
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
OC4J is good indeed!
Gustavo, the good news I take from your post is happiness with TopLink - both the reference implementation that Oracle provided as part of Glassfish and, in case you did not know, also ships with OC4J 10.1.3.1 (presumably why you are seeing equivalent performance between the two) but also its great to hear positive comments on the full fledged TopLink product line.
However, I can't say, being from Oracle and the Java platform group product management team, that the prospective switch out of OC4J for Glassfish is something I am keen to hear! If you have specific issues with OC4J, I would appreciate a note from you on issues you are facing and the version you are using - I can be reached at mike.lehmann@oracle.com.
Mike Lehmann, Oracle
Java Platform Group
Product Management
Mike! Like I said, we are evaluating Glassfish ATM. Actually, we are currently using OAS 10.1.3 for Java (ADF Faces + EJB3) applications and 10.1.2 backing our Colaboration Suite and Portal servers. Also, we run Oracle E-Business Suite 11.5.10, so we are strongly tied to Oracle. Glassfish would be a replacement for our Java servers as they run ADF with no problem, at ZERO cost. That's it!
Regards,
Gustavo
PS: Sorry for my poor English!
|
|
|
Message #227416
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Comparison
Gavin -
I can't comment about performance of Hibernate vs. Kodo in WebLogic, since I've never tried it.
As a result of this thread, I received some follow-up information from another "interested party" (i.e. having potential bias) that indicated that the tests they were doing (including Hibernate, OpenJPA née KODO, TopLink) showed that Hibernate was significantly faster than OpenJPA, which indicates that BEA stripped out a lot of the performance-related pieces of KODO (e.g. query caching) when they opened it up.
Again, I don't have the tests (or the difs between KODO and OpenJPA) to verify and understand the results, but they were certain that even on simple CRUD (i.e. not using query caching), Hibernate currently held an advantage over OpenJPA.
Since OpenJPA is publicly available, I would be curious if anyone (including anyone on the Hibernate team) has run any comparisons. Also, "TopLink essentials" is open source, so we could easily have a simple 3-way comparison of the open source versions of the products.
Cameron, it would have been better [..] to identify the source of those statememts
You know how it is .. if they could speak publicly, they would.
I'm now even more curious what the results would look like of a benchmark comparison. I know that they are irritating to the implementers (e.g. you), but with such broad differences in results from various testers, I am guessing that benchmark submissions (including configurations and optimizations) would serve as good documentation for both what to do and (in some cases) what not to do, which would be pretty valuable to developers using any of these solutions.
Peace,
Cameron Purdy
Tangosol Coherence: Clustered Caching for Java
|
|
|
Message #227450
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Perf
Gavin,
Would it be possible to provide some more information about the measurements you did? Specifically:
1. What versions of Kodo and Hibernate was used?
2. What hardware/JVM/OS/db was used?
3. Was it ensured that no other piece of the system - i/o, db - was a bottleneck?
4. What was the standard API that was compared - JDO or JPA?
5. Were the measurements taken with multi-threaded access?
6. Would you happen to remember what kind of response-time or throughput you got with Kodo?
A couple of lines about the use-cases measured would be nice too, if you have the time to put it in and it's not a problem.
Thanks!
Arunabh
Arunabh, you really shouldn't pay any more attention to my benchmark than to any other benchmark you see out there. They all suck! It was a microbenchmark with all the same flaws as all microbenchmarks. It doesn't represent real usage.
The history of this is that at the time of the BEA acquisition of Solarmetric, some BEA spokesdrones were out there in the press talking about how Kodo was "faster than Hibernate". This took me by surprise, since it was the first time I had heard that claim. So we did some tests and I really didn't find anything to substantiate it (I figured it was something the Solarmetric guys had told the BEA guys in order to get the deal done). But "faster" all depends upon how and what you test. Another different kind of test may have shown Kodo significantly "faster" than Hibernate, who knows?
The point is that the only benchmark that matters is *your* unbiased benchmarks of
(1) your application,
(2) running in your deployment environment,
(3) under a typical production load
If any of these three conditions are not satisfied, then you may as well read tea leaves.
|
|
|
Message #227451
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Comparison
As a result of this thread, I received some follow-up information from another "interested party" (i.e. having potential bias) that indicated that the tests they were doing (including Hibernate, OpenJPA née KODO, TopLink) showed that Hibernate was significantly faster than OpenJPA, which indicates that BEA stripped out a lot of the performance-related pieces of KODO (e.g. query caching) when they opened it up.
Or it simply indicates that benchmarks of ORM products are unreliable.
Since OpenJPA is publicly available, I would be curious if anyone (including anyone on the Hibernate team) has run any comparisons.
We have not. However, in light of this thread it is probably about time we tried to find some time for something like this.
Unfortunately, we really don't have sufficient money and people to spare on designing an impressive-looking benchmark and then optimizing our product to do well on that benchmark. This is expensive, time-consuming work.
|
|
|
Message #227455
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Perf
The point is that the only benchmark that matters is *your* unbiased benchmarks of
(1) your application,
(2) running in your deployment environment,
(3) under a typical production load
If any of these three conditions are not satisfied, then you may as well read tea leaves.
+1
|
|
|
Message #227457
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Comparison
Hi Cameron,
I see the comparison issue as more to do with risk then outright performance. What is the risk that implementation X proves to be too slow for my application?
If the implementation is fast enough, then I need not worry about performance IMO, and other factors come to the fore.
What we have done with our ORM implementation is to keep it behind an Interface as a risk mitigation measure. So we have an IPersistenceManager interface that is used throughout our code. We then inject a concrete implementation HibernatePersistenceManager through Spring.
We are currenty tuning Hibernate now for performance, and I am quite sure that the issues that we are now facing have more to do with poor design on our part, more than anything else (I've got specifc questions for Gavin, but I guess I should save those for the Hibernate forum if there is such a thing).
But if finally we decided that we needed to evaluate/shift to a different ORM implementation then we could easily do so. For example we could implement an OpenJPAPersistenceManager that satisfied our IPersistenceManager interface and change our Spring configuration accordingly.
So I loose very little sleep worryng about benchmarks :^)
Paul.
|
|
|
Message #227467
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: WebLogic Server 10
Now that most of the arguments about ORM soultion is over , lets talk about weblogic 10 :)
i like that finally i can override what the server class path contains.
its frustating to deal with vendor class path as it hardly allows you to override it and if you do then stuff starts breaking internally and its not supported.
I have one question for bea folks - do i need to go to weblogic 9 to be on 10 > or can i jump from wl-8 to wl-10.
do i have to use jee5 / jse 5 or can i be on jdk1.4 with wl 10
|
|
|
Message #227470
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: WebLogic Server 10
do i need to go to weblogic 9 to be on 10 > or can i jump from wl-8 to wl-10.
You can go straight from 8 to 10.
do i have to use jee5 / jse 5 or can i be on jdk1.4 with wl 10
Your client code can use J2SE 1.4. However, the server must run with Java SE 5.
Java EE 5 is fully backwards-compatible with J2EE 1.4, so you can certainly ignore all the new stuff in Java EE 5 while using WebLogic Server 10.
-Patrick
--
Patrick Linskey
http://bea.com
|
|
|
Message #228325
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
re: Reference Implementation ...
Actually, a Reference Implementation is just a legal term within the JCP process. Any spec that goes final includes a Specification, a TCK, and an RI. The TCK is a test suite for the spec; the RI is an implemetnation of the spec (that passes the TCK).
An RI can range from a proof-of-concept to a production-ready implementation.
The Java SE RI is the JDK from Sun. The Java EE RI is GlassFish.
It used to be that the Java EE RI was not production-ready; we stopped doing that years ago - it was just too expensive to have two implementations. GlassFish is production ready, check http://blogs.sun.com/stories for a few stories on the existing release (v1); we have many more in the pipeline.
- eduard/o
|
|
|
Message #228326
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Great!
.... We're not there yet, but it's getting close. Jboss AS 5 beta 1, Tomcat 6.09beta and now WebLogic 10 TP (of course, Glassfish doesn't count since the public opinion is to avoid using Sun software except for the JDK, right?)
That's funny. Guess what Web Services implementation is used in WebLogic 10 TP? Right! GlassFish. Except that they are using the "old" implementation, from v1 - the new one, v2, has much better performance and functionality, including all the interoperability with Microsoft features.
For more information on GlassFish's JAX-WS, check out these entries in TheAquarium: http://blogs.sun.com/theaquarium/tags/jax-ws
- eduard/o
|
|
|
| MessageMessageMessage |
|
|
Thank you for replying to a message on TheServerSide!
Your reply has been successfully posted.
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
