I have a grails app that uses the Spring-Security-Core plugin, which integrates Spring Security 3 into my app. I belive that Spring/Hibernate will do some transactional operations under the hood. If that is the case, would it be better to use mysql's innodb engine instead of the default MyIsam engine? or are the operations independent of the underlying database?
Thanks in advance!
There's nothing particularly transactional about how the plugin works. It only reads - the primary database access will be loading a user and the user's assigned roles. You will want to use transactions when updating the user, assigning roles, etc. but that has nothing to do with security, it's just the right thing to do.
As the others said, there's very little reason to use MyISAM except in specialized use cases that are probably better suited for a NoSQL database. InnoDB is very fast and has excellent transaction support.
InnoDB enforces referential integrity; MyISAM does not.
Looks like MyISAM does not support transactions/rollback:
http://dev.mysql.com/doc/refman/5.0/en/ansi-diff-transactions.html
So if a transaction manager is required, better to go with InnoDB.
Actually i think innodb engine will be wise choice. Main reason - durability and data integrity support. MyIsam more "fragile". Only reason to use it now- huge insert activity - and this is not your case( i try to not go too deep in it- it more complex and don't connected with question).
Related
My site runs on a VDS-server. I've just found out that my MySQL server doesn't support InnoDB engine, therefore I can't use database transactions in my application.
It makes me think, that some people might never use transactions. Is this the case? If so, how does one manage to coordinate related operations on different tables in MyISAM?
Otherwise, is there a way to install InnoDB on a MySQL server which is run on a VDS?
Thanks!
If you need transactions, then you need transactions and MyISAM isn't going to cut the mustard.
Some applications won't need transactions. For example; an application that never runs more than one related SQL statement at a time and has no need to rollback multiple SQL statements. Another example is an application that uses MySQL as a simple Key-Value Store. There are many use cases that don't require database level transaction support.
It's hard to answer the second part of your question without knowing more details about your VDS. Who is you hosting provider? Do you have shell access and permissions to change my.cnf? If not, then you probably won't be able to enable InnoDB. If you do, then here is a another SO answer that details how to enable InnoDB on MySQL: How to enable INNODB in mysql
You can often either enable the engine, install the InnoDB components manually, or simply re-install a version of MySQL that includes that engine by default. MyISAM is the crazypants database, stupidly fast but also unreliable and prone to complete destruction if your system isn't shut down properly.
Running a mission critical application on MyISAM is an extremely bad idea. Where you need MyISAM tables for performance reasons they should always be disposable, easily re-built from another more reliable source of data.
I am on a college project for a social networking web application. I am over with the schema design part.I am using PHP+MySQL. Right now I am testing the application and the tables are MyISAMs. But I got to know that myISAM doesn't provide row level locking but at table level. So I am confused whether I need to switch to InnoDB. I am expecting a 8:3 select v/s update and 30 updates per second is my threshold limit. I am relying on shared hosting server. So please help me with it. Love to hear from a Database EXPERT...
I would recommend InnoDB engine, because it has better performance in OLTP.
MyISAM is too fast when used in non-concurrent (or low concurrent) queries.
Also you can take advantage of foreign key integrity.
Hope this helps.
Is there any way to tell Hibernate use MySql Memory Storage Engine?
Thanks.
Edit: I found Memory Storage Engine does not support all features of a regular Store Engine like InnoDB, etc. So it may be seemed logical that there is no option for it.
There should be a properties file where you can put your URL to MySQL
#hibernate.dialect org.hibernate.dialect.MySQLDialect
#hibernate.dialect org.hibernate.dialect.MySQLInnoDBDialect
#hibernate.dialect org.hibernate.dialect.MySQLMyISAMDialect
#hibernate.connection.driver_class com.mysql.jdbc.Driver
#hibernate.connection.url jdbc:mysql:///mysqlURL
#hibernate.connection.username
#hibernate.connection.password
But be aware of this
When using the MyISAM storage engine, MySQL uses extremely fast table locking that allows multiple
readers or a single writer. The biggest problem with this storage engine occurs when you have a steady
stream of mixed updates and slow selects on a single table. If this is a problem for certain tables, you can
use another storage engine for them.
The storage engine used by mySQL is declared when you create your tables. Use the qualifier ENGINE=MEMORY at the end of your CREATE TABLE DDL. Then use it like any other table.
But, of course, remember that if your mySQL server bounces for any reason, all rows will be gone from that MEMORY table when it comes back.
Why do you want in-memory storage?
My personal use case scenario for such a setup is testing.
Think about using h2, hsql or derby. AFAIK they all provide in-memory storage. And if you consistently use Hibernate, it should make no difference which database runs in the background -- at least not from a development standpoint.
Obviously, there is plenty out there about MyISAM vs InnoDB engine selection, but I couldn't find anything specific to JPA2.
Is it possible to use a MyISAM engine together with java persistence API, and still have transaction support? Or does it rely on the RDBMS to provide rollback / commit functionality?
Are there other (non-obvious) factors that need to be considered? What about #Cascade?
I found this posting, which makes a pretty good case for using transactional RDBMS backends.
I managed to reproduce the behaviour:
Create an entity
Within the transaction, throw an Exception
With MyISAM, the entity will remain created. With InnoDB, the entity is created, but then rolled back. So even though I haven't been able to find something official, I am convinced that a transactional backend is required if one expects container-provided transactions to work.
Many sites and script still use MySQL instead of PostgreSQL. I have a couple low-priority blogs and such that I don't want to migrate to another database so I'm using MySQL.
Here's the problem, their on a low-memory VPS. This means I can't enable InnoDB since it uses about 80MB of memory just to be loaded. So I have to risk running MyISAM.
With that in mind, what kind of data loss am I looking at with MyISAM? If there was a power-outage as someone was saving a blog post, would I just lose that post, or the whole database?
On these low-end-boxes I'm fine with losing some recent comments or a blog post as long as the whole database isn't lost.
MyISAM isn't ACID compliant and therefore lacks durability. It really depends on what costs more...memory to utilise InnoDB or downtime. MyISAM is certainly a viable option but what does your application require from the database layer? Using MyISAM can make life harder due to it's limitations but in certain scenarios MyISAM can be fine. Using only logical mysqldump backups will interrupt your service due to their locking nature. If you're utilising binary logging you can back these up to give you incremental backups that could be replayed to aid recovery should something corrupt in the MyISAM tables.
You might find the following MySQL Performance article of interest:
For me it is not only about table locks. Table locks is only one of MyISAM limitations you need to consider using it in production. Especially if you’re comming from “traditional” databases you’re likely to be shocked by MyISAM behavior (and default MySQL behavior due to this) – it will be corrupted by unproper shutdown, it will fail with partial statement execution if certain errors are discovered etc...
http://www.mysqlperformanceblog.com/2006/06/17/using-myisam-in-production/
The MySQL manual points out the types of events that can corrupt your table and there is an article explaining how to use myisamchk to repair tables. You can even issue a query to fix it.
REPAIR TABLE table;
However, there is no information about whether some types of crashes might be "unfix-able". That is the type of data loss that I can't allow even if I'm doing backups.
With a server crash your auto increment primary key can get corrupted, so your blog post IDs can jump from 122, 123, 75912371234, 75912371235 (where the server crashed after 123). I've seen it happen and it's not pretty.
You could always get another host on the same VLAN that is slaved to your database as a backup, this would reduce the risk considerably. I believe the only other options you have are:
Get more RAM for your server or kill of some services
See if your host has shared database hosting of any kind on the VLAN you can use for a small fee.
Make regular backups and be prepared for the worst.
In my humble opinion, there is no kind of data loss with MyISAM.
The risk of data loss from a power outage is due to the power outage, not the database storage mechanism.