2

I developing small application with play 2.0.1 and find very usefull using internal H2 database for make customer's preview. There are just few rows in database and one or two users. It is very comfortable to compile app in my laptop and make tar for deploying on test server. But it looks like H2 falls from time to time. I found this in my application.log:

! @6anj14ljo - Internal server error, for request [POST /admin] ->

play.core.ActionInvoker$$anonfun$receive$1$$anon$1: Execution exception [[PersistenceException: Query threw SQLException:table "MANAGER" not found.

I know using H2 for production is not a good idea. But I don't want to configure mysql each time. Which the reason of such H2 behaviour?

biesior
  • 55,576
  • 10
  • 125
  • 182
Alex Povar
  • 4,890
  • 3
  • 29
  • 44
  • 2
    I have no idea what the problem could be. Could you provide a reproducible test case? See http://sscce.org/ – Thomas Mueller Jun 25 '12 at 10:22
  • It is hard to provide test case. The reason is that I have few small apps, they are all different, but sometimes all of them in pre-production mode failes to access DB (preproduction means doing play clean compile stage, but with embedded inmemmory H2) It is not kind of problem which I can reproduce by action sequence. They just happened and I cannot find any reason for that. – Alex Povar Jun 25 '12 at 13:36
  • Do you use eclipse as your editor. I have found that if I have eclipse open sometimes when I make changes I get these errors with h2. I found the only way i could guarantee to get it to work was close eclipse. Close play and run 'clean', 'update' and then 'run'. – user1434177 Jun 28 '12 at 01:10

2 Answers2

5

Use h2-browser to check state of your database, and if structure is the same as excepted:

in terminal/commandline

  1. play
  2. h2-browser - it will open h2-browser in new browser window
  3. ~run
  4. Perform evolutions
  5. Go to the window with h2-browser and connect using the same path as you gave in application.conf in db.default.url

On the other hand, oposite to you, I found, that using different databases in development and production mode can be annoying. There are things very specific for each DB engine and you need to resolve some problems twice, once for H2 - later for MySQL. That doesn't make sense, what's worse each time you're restarting the app in dev mode, you need to fill it again with sample data for debugging. Maybe between restarts you forgot to add some record etc.

Although the last problem can be solved by inserting the same set of test data with Global object in onStart() method it will be just more comfortable to keep the test data in MySQL between restarts.

Of course if you're still want/need use H2 you can also use it in file mode by removing the mem segment from the url, then it will be persisted on the disk.

biesior
  • 55,576
  • 10
  • 125
  • 182
  • Is it able for compiled app? I have no play installed on test server. Anyway its a good idea to try file mode. I completely loose it from my sight. – Alex Povar Jun 25 '12 at 13:40
  • Probably yes, but you need to check, I'm using MySQL on production, so I don't know how it will be working with in-file h2. Anyway if you'll check it let me know pls. – biesior Jun 25 '12 at 14:08
  • Looks like there is no way to start web interface of embedded h2. Maybe some tricks from in-project code can help. But that is bad idea. – Alex Povar Jun 26 '12 at 14:09
  • What do you mean ? I don't understand, maybe describe the problem in separate question ? – biesior Jun 26 '12 at 14:11
  • This is great, didnt know about h2-browser. Thanks! – malmling Sep 13 '13 at 12:23
0

Did you configure your DB not to drop the tables in case there are no connections? From the documentation it says that you have to append DB_CLOSE_DELAY=-1 to your db url in the configuration file in order to prevent such behavior.

I have been getting the same error as you when I was running a "production" app with in memory database in a docker container. After a while that I was running it and not interacting with it, the tables would be dropped.

Appending the DB_CLOSE_DELAY=-1 flag seems to have fixed it

Thomas
  • 2,751
  • 5
  • 31
  • 52