wuwen5 opened a new pull request, #8125:
URL: https://github.com/apache/incubator-seata/pull/8125
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<!-- Please make sure you have read and understood the contributing
guidelines -->
- [x] I have read the
[CONTRIBUTING.md](https://github.com/apache/incubator-seata/blob/2.x/CONTRIBUTING.md)
guidelines.
- [ ] I have registered the PR
[changes](https://github.com/apache/incubator-seata/tree/2.x/changes).
### Ⅰ. Describe what this PR did
This PR fixes the table metadata cache refresh behavior in
`AbstractTableMetaCache`.
Previously, `TABLE_META_CACHE.put(...)` was only executed when the latest
fetched `TableMeta` was different from the cached value. Since the cache uses
`expireAfterWrite`, unchanged table metadata would not renew the write
timestamp during periodic refresh, causing active cache entries to expire after
900 seconds.
This PR removes that restriction and always writes the refreshed `TableMeta`
back to `TABLE_META_CACHE` during `refresh(...)`. The change detection logic is
kept only for logging, so the cache write time is continuously renewed even
when the schema has not changed.
### Ⅱ. Does this pull request fix one issue?
No.
### Ⅲ. Why don't you add test cases (unit test/integration test)?
This change is a small behavior adjustment in the cache refresh path and
does not introduce new public behavior or API changes.
Also, verifying this issue through automated tests would require time-based
cache expiration behavior and scheduled refresh coordination, which makes the
test relatively heavy and less stable. The logic change itself is
straightforward: always renew the cache entry during refresh, while preserving
the existing schema change log behavior.
### Ⅳ. Describe how to verify it
1. Configure a datasource and ensure table metadata can be loaded into
`TABLE_META_CACHE`.
2. Trigger periodic `refresh(...)` calls with unchanged table schema.
3. Confirm that `TABLE_META_CACHE.put(...)` is executed on every refresh.
4. Observe that the cache entry write timestamp is continuously renewed.
5. Verify that the cache entry does not expire after 900 seconds while
refresh is running normally.
6. Optionally modify the table schema and confirm that the existing info log
is still printed when metadata changes.
### Ⅴ. Special notes for reviews
This PR intentionally keeps the existing log behavior unchanged:
- cache entries are always rewritten during refresh
- the info log is still printed only when the fetched metadata differs from
the previous cached value
The goal is only to ensure `expireAfterWrite` entries remain alive during
normal periodic refresh.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
