Jersey与Hibernate部署至Linux服务器时出现数据库锁获取失败

听起来你碰到的这个跨环境部署问题挺典型的，我来拆解下可能的原因和对应的解决思路：

1. 先排查文件路径配置差异 #

Windows和Linux的路径规则不一样，而且远程Tomcat的工作目录大概率和你本地项目根目录不是一回事：

• 如果你在Hibernate配置里用的是相对路径（比如jdbc:hsqldb:file:data/mydb），本地运行时data文件夹会在你执行mvn tomcat7:run的目录生成，但远程部署后，Tomcat的工作目录可能是它的bin目录或者webapps下的项目子目录，导致HSQLDB找不到正确的路径，甚至尝试在没有权限的目录创建文件，进而触发锁错误。
• 解决办法：改成绝对路径，比如在远程服务器上指定jdbc:hsqldb:file:/opt/tomcat/webapps/your-project/data/mydb，或者用Tomcat的环境变量动态获取项目路径，确保HSQLDB能准确定位到数据库文件目录。

2. 验证目录权限是否足够 #

Linux系统对文件权限要求很严格，Tomcat运行用户（通常是tomcat或者你部署用的登录用户）必须对数据库文件所在的data文件夹有读写权限：

• 远程登录服务器，找到你期望存放数据库文件的目录，执行ls -l查看权限详情；
• 如果权限不足，执行sudo chown -R tomcat:tomcat /path/to/data（把tomcat换成实际运行Tomcat的用户/用户组），再用chmod -R 755 /path/to/data赋予读写执行权限；
• 建议提前手动创建好data目录，不要依赖HSQLDB自动创建（虽然它支持自动创建，但权限问题可能导致创建失败）。

3. 检查HSQLDB锁文件残留 #

如果之前的Tomcat进程没有正常关闭，HSQLDB会残留.lck锁文件，导致新启动的进程无法获取数据库锁：

• 找到数据库文件所在的data目录，查看是否存在类似mydb.lck的文件；
• 如果有，先停止Tomcat服务，删除这个锁文件，再重新启动或者执行mvn tomcat7:redeploy。

4. 确认连接配置的兼容性 #

HSQLDB的文件模式有一些参数可能影响锁机制，你可以检查下：

• 确认JDBC URL没有错误添加hsqldb.lock_file=false（除非是只读场景，否则不建议关闭锁）；
• 检查Hibernate的hibernate.connection.autocommit设置是否合理，避免因为事务未提交导致的锁长期持有问题。

你可以先从路径和权限这两点入手排查，这两个是跨环境部署时最容易踩的坑。

内容的提问来源于stack exchange，提问作者GrzegorzK