Recently, I have suffered a wired problem when using Ebean to update item. When I update it by doing following:
Then when I run this code, the save() statement give me a exception:
The update code is pretty simple, and so does the definition of SomeEntity.
(If you just want a quick solution, refer to the next section)
According to avaje’s document, OptimisticLock is a mechanism to avoid lost of updates when these updates occur in the same time on the some data.
This mechanism is very simple: check if old data has been changed. If the attributes before updated have been changed by other threads, the update will be abort by throwing OptimisticLockException.
There are two ways for Ebean to decide whether the old data has been changed:
check all the attributes.(default way)
check one special attribute defined by user named as Version Attribute.
The first one is how problem came out. When I performed save(), the Ebean actually mapped it into following sql:
This sql seems innocent, and it works well in the most time. However sometimes it can fail even if on one has changed the data. That is because sometimes database saves data as different value(to optimise the storing I guess). This could happen to double or text type of data. This will cause the where clause above fails, and make this update exceptional.
It can happen that you retrieve in your Java code something like 0.46712538003907 but in fact, in the database, the data stored is something like 0.467125380039068. When updating, the Java value will be included in the WHERE clause and, as it doesn’t match the value stored in the database, the update will fail.
Solution: Version Attribute
By adding Version Attribute to the model, you can specify Ebean only use this column to decide whether old value has been changed.
You don’t need to change anything in the updating code. Now if you perform an update, the sql statement will be:
And problem should be solved.
Note that OptimisticLock only happen in READ_COMMITTED Isolation level. So if you use transaction when update somehow, you might just walk around this problem.
Using config file absolutely make your life easier to deploy, debug, and test your applications.
Sometimes people want to use different config file to run dev or run prod, Sometimes people just want to use different config to test.
So, I’m going to show how to use multiple config files in sbt project.
In this post, I create minimal project by using typesafe’s activator, and I strongly command this tool to create small and clean project with least dependency to train skills.
Normal way to use config in sbt project
Firstly, create simple sbt Scala project. I created it by using activator:
And then follow the command wizard to choose minimal-scala as your project type, and fill up the project name.
To load config file, you will need one extra dependency: typesafe’s config.
And following to the build.sbt file under the root directory of the project.
Now your build.sbt file should looks like:
Ok, by now, you could use a module named ConfigFactory in your project to load your config files.
It’s time to add your own config file.
Add application.config under your src/main/resources, and write some random configs into it.
Here is mine:
To check whether this config file could be properly loaded, write a simple program to check it out:
When run this script, it will give:
Use config in your test
In most cases, people use a set of different configs in their tests.
It would be great if one can just replace some of the configs in the src/main/resources/application.conf and keep the others.
Actually, when run sbt test, sbt will first look for src/main/resources/application.config and then use src/test/resources/application.confg to overwrite configs in the first one.
Note: sbt will do the overwrite even if you not use include "application.config" in the src/test/resources/application.config.
To check that, add new test case under src/test/scala in your project:
Then add config file for the test as src/test/resources/application.conf.
When you run sbt test you will get this as expected:
Use specific config file
Normally, you can specify the config file by use sbt parameter -Dconfig.file or -Dconfig.resource.(for detailed information please refer to this doc)
But in team work, you probably want this to be static, and use the file you have specified whenever and whoever run sbt test.
In that case, you need to put a extra in your build.sbt:
And then, put your test.conf to the src/test/resources/test.conf:
Note that in this time you will have to use include "application.conf".
And this time when you run sbt test, you will get:
That is because the sequence of config files overwrite each others is:
Note that no matter you like or not, once you include the “application.conf”,
the sbt will first try to find src/test/resources/application.conf.
If that does not exist, then it will find src/test/resources/application.conf.
Even if you delete the src/test/resources/application.conf, the src/main/resources/application.conf is still in the system.
Here is the result if there is no src/test/resources/application.conf in the project:
In my last memo about how to use logback in Akka to log into file system, I showed the way to config logback.xml.
However, recently I find it killing me when I use this log file for bug-shooting, because all the log, including debug, info, warning, error are all in one file. And what I am really looking for is error, which is really rare in the log file.
So, it seems reasonable to place logs of different level into different files. In my case, which would also cover most cases, I will place all the info log line into info.log, and all the error log and above to the error.log.
Since we are place log into different files, we are going to use multiple appenders.
To put info log one file
The key point is in the filter element. This filter uses LevelFilter to decide which level of log should be logged.
To put error and all levels above to another file
In this example, we use ThresholdFilter to select all the levels above the error to log file.
Then, put two appenders together
This is the tricky part. We ganna use two root logger in the same logback.xml.