Ok, here comes a large post.
You are right in mentioning the .dbi files. That is where column information is kept in developer (as the 'repository' of a developer is made up of files in the workspace).
But in application server, the same information is stored not in .dbi files but somewhere in the repository DB server (that is the 'repository' when running from the app. server).
Column information keeps information
- relevant to Servoy - about columns. For example: if a column is a servoy seq., defaults, auto-enter, column converter name and so on...
Let's say you have two tables A and B.
After you did the .servoy import of your solution in the app. server through admin page, Servoy had column information about columns colOneA and colTwoA from table A and about columns colOneB and colTwoB from table B.(either because the .servoy file didn't contain that information or because the columns were really not yet there in the DB)
Then you restart tomcat or redeploy.
When Servoy app. server starts it finds on two separate execution threads that I described earlier that:
- table A actually has in the database also colThreeA but it does not find column information about that column in the Servoy repository (this is what one thread finds)
- table B actually has in the database also colThreeB but it does not find column information about that column in the Servoy repository (this is what the other thread finds)
Both threads try to generate a default column information for their column (colThreeA and colThreeB), which is normal and it works like that since I can remember. Because of some implementation details on how code acquires locks on those threads and what locks they already have (these details have changed in 8.2.3), the two threads end up waiting indefinitely after each-other. So it doesn't last longer, it lasts forever...
It doesn't seem related to licenses at all. But as almost all bugs where threads block each-other are involved it is possible that having a license delayed a bit one of the two threads; so that it made it more likely to get into this situation. If the two threads would not execute those parts of code at the same time - so thread 1 finished it's job before thread 2 found it's 'special' column then the two threads would not have blocked each-other. Also if Servoy would not detect at all columns for which it has no column information, the deadlock would not occur.