[OPENJPA-2963] Track dropped tables per database, not per JVM

[rzo1]

The dropped-table tracking was one JVM-global set, and clearDroppedTables() is called whenever any factory with schema-generation properties starts up, so two persistence units initializing at once wiped each other's in-flight tracking. Keys were bare table names too, so two units on different databases with a table of the same name aliased onto one entry.

The set is now partitioned by the database a configuration connects to, and the clear empties only that database's entry. Every access holds one monitor, including the trace line, which previously interpolated the live set while another thread could be writing to it. The no-arg clearDroppedTables() is kept and deprecated.

On the suggestion to move the state onto the configuration: that is not available. The tracking has to outlive the configuration that wrote it — Persistence.generateSchema() closes its own factory, and a later, separately created factory is expected to see what it dropped, which TestSchemaGenDrop.testDropViaGenerateSchema pins. Config-scoped, the set would have almost no readers and that test would fail. So the state stays static and is scoped instead.

On the locale half of the issue: it no longer applies. 53269ab already gave every one of those call sites Locale.ROOT; the line numbers in the issue are from before it.

Deliberately not addressed here, each worth its own issue:

• The DDL name matching still compares a regex-stripped fragment of the raw statement against a schema-qualified identifier, so it both misses (DROP TABLE IF EXISTS FOO yields an empty key; DROP TABLE ORDER_CASCADE_LOG yields ORDER_) and over-matches. Fixing it in isolation would make things worse rather than better: more names would match, so any suppression defect would fire in more configurations than it does today.
• It was suggested that a drop-and-create with a script drop source suppresses the create it is paired with, because both run in one action list against one configuration. I wrote the fix and a test for it, and the test passed against unpatched master — with an explicit drop-source=script and with a verifying factory that has no SynchronizeMappings and so cannot create the table itself. I could not reproduce it, so the fix is not included.

There is no new test. The concurrency defect is not deterministically testable, and the one testable claim did not reproduce; the change rests on the existing schema-generation suite (35 tests, passing).

[cristof]

Could you provide an unit test for the issue? It would help to avoid future regressions.

[rzo1]

Added TestSchemaToolDroppedTables (openjpa-jdbc, no database needed). The producer and consumer moved into two package-visible methods so the behaviour has a seam to test through, and it covers:

• one persistence unit does not see another's drop, and clearing one leaves the other intact — the actual defect;
• two factories of the same unit do share the tracking, so the generateSchema()-then-buildSchema flow keeps working;
• a create forgets the entry, and outside spec-compliant mode the entry suppresses one create only;
• the key falls back to the connection when a configuration has no id.

The two partitioning cases fail if the map is collapsed back to a single global set, which I checked rather than assumed.

Note the concurrency itself is still not covered: two persistence units initialising at the same time is not deterministically reproducible in a unit test, so the tests pin the partitioning that makes the interleaving harmless rather than the interleaving.