I am using Spring MVC for an application that involved a multilevel back end for management and a customer/member front end. The project was initially started with no framework and simple native JDBC calls for database access.
As the project has grown significantly(as they always do) I have made more significant database calls, sometimes querying large selection sizes.
I am doing what I can to treat my db calls to closely emulate Object Relational Mapping best practices, but am still just using JDBC. I have been contemplating on whether or not I should make the transition to hibernate, but was unsure if it would be worth it. I would be willing to do it, if it was worth a performance gain.
Is there any performance gain from using Hibernate( or even just Object Relational Mapping) over native SQL using JDBC?
Is there any performance gain from using Hibernate (or even just Object Relational Mapping) over native SQL using JDBC?
Using an ORM, a datamapper, etc won't make the same SQL queries run faster. However, when using Hibernate you can benefit from things like lazy loading, second level caching, query caching and these features might help to improve the performances. I'm not saying Hibernate is perfect for every use case (for the special cases Hibernate can't handle well, you can always fall back to native SQL) but it does a very decent job and definitely improves development time (even after adding time spent on optimization).
But the best way to convince yourself would be to measure things and in your case, I would probably create an Hibernate prototype covering some representative scenarios and bench it.
ORM lets you stay inside OOP world, but this comes at the cost of performance, especially with many to many relations in our case. We were using Hibernate as default, doing performance optimization with jdbc where required.
Hibernate will make the development and maintenance of your app easier, but it won't necessarily make DB access quicker.
If your native JDBC calls use inefficient SQL then you might see some performance improvement as HIbernate tends to generate good SQL.
Related
Today I've found some interesting library - ActiveJDBC. It provides RoR-like ActiveRecord interface, and I'm thinking on Hibernate replacement, but there is a question - can ActiveJDBC handle really big queries and results and is it clever to use it instead of Hibernate in any application?
I'm a developer of ActiveJDBC, so take my advice with a grain of salt :). I have not performed extensive performance comparison tests, but simple tests (storing and reading tens of thousands of records) revealed that ActiveJDBC is about twice as slow as JDBC, and Hibernate is about twice as slow as ActiveJDBC, which makes Hibernate about 4 times slower than plain JDBC. Overall, ActiveJDBC is a lot thinner than Hibernate, that was the idea for developing it. Please see this blog: Just how thin can a framework be? ActiveJDBC vs Hibernate.
Hibernate is architecturally built with client/server model in mind in the 90s (sessions, lazy loading, object graphs. etc.), while ActiveJDBC was built in 2009 primarily for request/response of modern web applications and uses a pass-through model. Depending on your logic, data and database optimizations, your mileage will vary, but I'm confident that ActiveJDBC will almost certainly be faster.
Mubin pointed out the fact that you will need migrations. I'd say this is partly correct. Migrations system is always a good idea, but ActiveJDBC does not care how tables were created, as long as they exist.
cheers
I am looking for best solution for caching large amount of simple transactional pojo structure in memory. Transactions happen at oracle database on 3-4 tables by external application. Another application is kind of Business Intelligence type, which based on transactions in database evaluates updated pojos(mapped to table) and applies various business rules.
Hibernate solution relies on transactions on same server; where as in our case transactions happen some where else, and not sure cached objects can be queried.
Question:
Is there oracle jdbc API that would trigger update event on java side?
Which Caching solution would support #1,
Is cached objects can be queried?
Oracle databases support Java triggers, so in theory you could implement something like this yourself, see this guide. In theory, your Java trigger could invoke the client library of whichever distributed caching solution you are using, to update or evict stale entries.
Oracle also have a caching solution of their own, known as Coherence. It might have integration like this built in, or at least it might be worth checking it out. Search for "java distributed cache" for some alternatives.
As far as I know Hibernate does not support queries on objects stored in its cache.
However if you cache an entire collection of objects separately, then there are some libraries which will allow you to perform SQL-like queries on those collections:
LambdaJ - supports advanced queries, not as fast
CQEngine - supports typical queries, extremely fast
BTW I am the author of CQEngine. I like both of those libraries. But please excuse my slight bias for my own one :)
I am a java/j2ee developer. I always like JPA/JTA or hibernate for ORM. Since it gives me portability. But for large scale application, portability is not that important sometimes. Lots of time they ask to use PL/SQL as BE. I always find it un necessary. Apart from ARRAY and scheduling etc. Cos, with PL/SQL, application logic gets fragmented in java and PLSQL.
What are business / application scenario where PLSQL is better in-terms of performance / design / maintainability.
The answer to this usually depends on whether you prefer objects or relational databases.
A DBA would argue that middle tier applications come and go, but relational databases live forever. Portability is rarely important for relational databases, especially if a firm has made a large investment in Oracle. A decision to migrate to another vendor won't be made lightly.
A DBA may prefer stored procedures because it acts like a Java interface and shields users from the underlying schema details. S/he can modify the schema as will as long as the stored proc parameters don't change.
Sometimes stored procedures make sense for performance reasons. Why query for a large data set on the middle tier, process it, and put it back in the database when you can do all the calculations on the database server?
Using stored procs does force you to do maintenance on both middle tier and server, but that's a choice.
I don't believe there's a hard and fast answer that would say objects or stored procedures are always right. If that's what you're looking for, I'm afraid you're going to be disappointed.
Put it simply PL/SQL is the closer you can get to your Oracle DB therefore performance comes first in mind in situations where you are dealing with loads of database entries.
I'm wondering why is ORM so popular and everybody is using ORM implementations of JDO and JDA specifications, instead of using object databases that implements these specifications as well. The performance is much better using Object database.
objectdb (JDO, JPA)
db4o (JDO)
Am I right if I say that it is because developers need to use both object model and relational model in their applications ?
What about ORDBMs ? Is there any ORDBM (which worths a try) around or can Object Relational Mapping together with relational database be considered ORDBM ?
The main reason why people use an RDBMS with an OR Mapper rather than an object database is that RDBMS are deeply entrenched, well understood and well supported by everyone. If you use an object database you'll have problems
finding people to support it
using your existing tools for reporting, backups, etc.
having other applications access the data
There's probably also still a lot of doubts (whether justified or not I can't say) whether object databases can really deliver the same or better performance and safety in a real word scenario.
In my experience, using an object database resulted in much less code, and a much cleaner project.
It made the difference between a 6-week learning curve for an RDBMS + ORM (LINQ-to-Entities) and a 1-week learning curve for object databases (for db4o).
The commonly used DBMSs you may be familiar with (e.g. Oracle, SQL Server, DB2, MySQL, PostGreSQL) are not relational. They are based on the SQL model, which is something quite different even though it resembles the relational model in some ways.
An Object-Relational DBMS means the same thing as a Relational DBMS. It's another way of saying that a RDBMS in principle will support any unlimited set of data types and relational operations upon them. O/R Mapping software really only addresses the fact that SQL DBMSs don't do that very well.
I'm looking to add a pretty simple SQLite database to an existing Java EE application. I'm very used to using EJBs, ORMs, EntityManager, etc. to work with SQL databases. I've never not used some sort of ORM to work with relational DBs in Java.
I've been "recommended" to use a Java wrapper for SQLite, rather than a JDBC driver - so I'm kind of naked and ORM-less (right?). I'd like to get this up and running quickly.
Context
I've been using an in-memory cache, implemented as a Map, which gets filled with entries linearly over time. At some point, like when the app runs overnight, the cache will use all available heap space. Hence, storing the cache on disk (as a SQLite database) rather than in memory (as a Java Map).
Questions
How should I manage resources like SQLiteConnection? Normally I would let the container worry about all this, but since I'm not using JDBC, I have to do all this !##$%ing, non-value-added stuff manually - right?
Is there a way to implement this cleanly and transparently? I'd like to be able to just swap out an implementing class - e.g. replace FooMapCacheImpl with FooSQLiteCacheImpl.
"[Most] methods are confined to the thread that was used to open the connection". Is there a simple, straightforward way to ensure that I don't try to access a SQLiteConnection from threads other than the one that opened it?
...and the flip side of that question: can I avoid creating a new connection every time I want to read from/write to the database? It seems a bona fide PITA to have to manage connections per-thread rather than, say, per instance, which is how I've been thinking about communicating with databases in the past.
Basically
I'm rather lost when it comes to working with databases in Java/Java EE, without using an ORM.
What's the right way to do it?
I don't think It is too hard to make a front end that would implements Map and save everything to a database using JDBC, but before doing it, think twice about it. The performance of the whole system might be affected badly.
However, if the root cause of your problem is the lack of Heap space, you should take a look at Terracotta's BigMemory. However, it is a commercial (non-free) product.
Terracotta has a pretty good cache framework as well (ehcache) which is opensource. Look at the cookbook, it might be inspiring.
If you want to do everything by hand, and you don't mind using Spring, try spring-jdbc. It is very easy to integrate with any JDBC driver. Take a look at SimpleJdbcTemplate. It does all the boiler plate code for you. You should probably use a connection pool as well, such as commons-dbcp
The easiest SQLite JDBC driver to use is this one. Since it doesn't rely on JNI. It might not be as fast, but for quick testing it is perfect.
If you aren't binded to SQLite, you can take a look at other available JDBC solutions such as hsqldb or derby
I hope this will help you out.
You may also want to look at Berkeley DB Java Edition. It allows you to persist and manage Java objects directly in the library, without requiring an ORM (and the associated overhead). It runs on Android, it's an Java library and can manage data sets ranging in size from very small to very large. It was designed with Java application developers in mind and should be both faster and simpler to use than an ORM+RDBMS solution. You can find more out more about it on our web site at Oracle Berkeley DB Java Edition.
Regards,
Dave
The sqlite4java wrapper is basically a JNI wrapper, it is nowhere near what you want.
An ORM like eclipseLink would anyway be a layer on top of JDBC and the Entity manager would always end up using JDBC accesses.
Instead, sqlite4java allows you to call SQLite in java instead of having to do all the JNI wrapping yourself.
If you want to use an ORM and your preferred entity manager then you should use a JDBC driver and the sqlite4java wiki references a few of them.
Hope this helps.