IMO, direct JDBC is really flexible and most optimized way to do CRUD operations but in application perspective we can gain more performance optimization if we can use ORM tool since it has lot of performance specific features like 1st level caching, 2nd level caching (really useful for distributed in memory caching technique), using same jdbc connection for same jta-transaction, resource pooling and management .. etc. Most painful experience is had to use in-mature tools, because of that life becomes hectic rather than become easy. IMO, Hibernate is the best option but we won't be able to ship with our products.
Cheers, Dhanuka *Dhanuka Ranasinghe* Senior Software Engineer WSO2 Inc. ; http://wso2.com lean . enterprise . middleware phone : +94 715381915 On Fri, Jan 3, 2014 at 4:50 PM, Afkham Azeez <[email protected]> wrote: > When we wrote Tungsten, we were using Hibernate instead of direct SQL. > However, when we started implementing Registry, there were long discussions > on whether to use an ORM or direct JDBC, and we made the decision to use > direct JDBC since we didn't want an additional layer & there were arguments > about performance, even though even at that time, Hibernate had lots of > performance optimizations like a write through cache. > > > On Fri, Jan 3, 2014 at 2:11 PM, Anjana Fernando <[email protected]> wrote: > >> Hi, >> >> I saw that, we are cleaning up the registry/user-manager APIs for C5 and >> re-writing some stuff. So I was wondering, if we can use JPA instead of >> writing our own SQL scripts and writing the DAOs and maintaing them in the >> platform. Having our own SQL scripts and the SQL in the code can be a bit >> messy and it can get complicated when supporting new databases and so on. >> >> So, by simply using a JPA provider, we offload all these complexities of >> generating SQL for different types of database and all to the JPA >> implementation. And also, with this, we can also possibly support non-RDBMS >> data stores as well, like MongoDB, which is supported by EclipseLink and >> DataNucleus. >> >> I guess, the only concern with JPA would be any possible performance >> implications, but I guess now a days JPA implementations must be pretty >> optimised, and must be generating good SQL or maybe even better than our >> custom ones, where as, they can generate custom SQL per database type. And >> in the case of data stores such as MongoDB, we may want to check how >> transactions and all would work. So if possible, we can do a PoC and see >> how it can work out. >> >> Cheers, >> Anjana. >> -- >> *Anjana Fernando* >> Technical Lead >> WSO2 Inc. | http://wso2.com >> lean . enterprise . middleware >> > > > > -- > *Afkham Azeez* > Director of Architecture; WSO2, Inc.; http://wso2.com > Member; Apache Software Foundation; http://www.apache.org/ > * <http://www.apache.org/>* > *email: **[email protected]* <[email protected]> > * cell: +94 77 3320919 <%2B94%2077%203320919> blog: * > *http://blog.afkham.org* <http://blog.afkham.org> > *twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez> > * linked-in: **http://lk.linkedin.com/in/afkhamazeez > <http://lk.linkedin.com/in/afkhamazeez>* > > *Lean . Enterprise . Middleware* > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
