Stop attaching a stack trace to every cleanup SQL statement

[jcschaff]

Closes #1987.

DbDriver.StackTraceGenerationException is an empty marker exception, constructed on purpose and handed to the logger so log4j prints a call stack next to the message. In DBBackupAndClean.executeUpdate that stack is invariant — the method is only ever reached from the cleanup thread through this one path — so it identified nothing the message and logger name did not.

It is not free. cbit.vcell.modeldb is at debug on the db container (docker/build/vcell-db.log4j.xml:25), so every statement the cleanup runs was logged with a full synthetic stack trace: ~948 lines/day on production, roughly a quarter of that container's 3823.

Before / after

Both forms logged side by side through a debug configuration:

---- OLD ----
DEBUG DBBackupAndClean - executeUpdate() SQL: 'DELETE FROM vc_simulation WHERE ...'
cbit.vcell.modeldb.DbDriver$StackTraceGenerationException
	at LogShape.main(LogShape.java:10)

---- NEW ----
DEBUG DBBackupAndClean - executeUpdate() SQL: 'DELETE FROM vc_simulation WHERE ...'

Same DEBUG line, same SQL, no stack trace. The visibility the debug level was presumably enabled for is kept.

Switched to a parameterized call, which also lets the isDebugEnabled() guard go — log4j2 does not build the string unless the level is on.

Deliberately narrow

The idiom appears 56 times in vcell-server, and they should not all be treated alike:

level	count
lg.error	20	keep — fire on genuinely unexpected conditions such as changed != 1 after an update (DbDriver:3585), where the stack is the only thing identifying which of many call paths produced it
lg.trace	19	cost nothing while nothing enables trace
lg.debug	16	only this one is generating volume in a deployed configuration

One line changed, in the one place that is actually noisy.

🤖 Generated with Claude Code