- captureMicros is the time taken to capture the specific query plan
- whenCaptured is the time when the bind values were taken
The DefaultQueryPlanListener logging will include these in the
output it logs
java.util.ConcurrentModificationException
at java.base/java.util.HashMap$HashIterator.nextNode(HashMap.java:1493)
at java.base/java.util.HashMap$KeyIterator.next(HashMap.java:1516)
at java.base/java.util.AbstractCollection.toString(AbstractCollection.java:472)
at java.base/java.lang.String.valueOf(String.java:2951)
at io.ebeaninternal.server.core.DefaultBeanLoader.loadBean(DefaultBeanLoader.java:134)
at io.ebeaninternal.server.core.DefaultServer.loadBean(DefaultServer.java:475)
at io.ebeaninternal.server.loadcontext.DLoadBeanContext$LoadBuffer.loadBean(DLoadBeanContext.java:217)
at io.ebean.bean.InterceptReadWrite.loadBeanInternal(InterceptReadWrite.java:742)
at io.ebean.bean.InterceptReadWrite.loadBean(InterceptReadWrite.java:724)
at io.ebean.bean.InterceptReadWrite.preGetter(InterceptReadWrite.java:837)
at ...
The issue being that shutdown() // with no args was
not calling ShutdownManager.unregisterDatabase(this)
noting that shutdown(boolean, boolean) did.
This change merges the old shutdownInternal(boolean, boolean)
method into shutdown(boolean, boolean) and simplifies
shutdown() to just call shutdown(boolean, boolean).
In DatabaseConfig.isAutoLoadModuleInfo() it only used the querybean generated class registration is classes.isEmpty(). Changing this so that it only uses the loadModuleInfo flag.
This means, unless loadModuleInfo is set to false the classes that register with ebean will be a combination of both the explicitly registered ones plus the classes from the querybean generated EbeanEntityRegister.
In addition, this changes the classes from List to Set.
The history behind this is that originally there was a "profileId" concept where that was a int value that could be used as an "id" for a transactional method that we wanted to profile.
That went away and then the idea was that bytecode enhancement would determine the line number and we would use that but that was a bad idea and we ended up with lineNumber always as 0.
These days with StackWalker and DProfileLocation we can do this better that way so yeah. A followup to this is to add to the api a boolean flag as to whether a profile location should be with line numbers (which can change frequently due to refactoring etc)
These types then determine which functions are valid for the types. So:
- Number functions
- String/varchar functions
- Temporal Date, DateTime, Time functions
- Boolean functions
- Object being everything else
Typically useful for handling DuplicateKeyException where we expect
DuplicateKeyException to be thrown and catch it with the intention of
continuing processing using the same transaction.
Note that some databases like Oracle do not require this explicit
rollback() and would work without the rollbackAndContinue(). Postgres
in particular requires the rollback() call on the underlying connection
such that we can continue using that transaction/java.sql.Connection.
Note that in the existing test we can see that rollbackAndContinue()
is pretty close to being syntactic sugar. I think adding rollbackAndContinue()
is justified and complements the existing commitAndContinue().
robin.bygrave