BsoBird commented on PR #10688: URL: https://github.com/apache/iceberg/pull/10688#issuecomment-2226845799
@snazy Hello.I'm so glad you could get back to me. I'm just saying out loud the first thing that comes to mind: 1. Is everything done using rest-catalog? In many cases, users have their own server rooms, they are not using cloud products, and they do not intend to expose iceberg directly to untrusted users. In a network-isolated environment, there seems to be no need to introduce a separate rest-catalog to add complexity. 2. For more complex access environments, rest-catalog is effective.I agree. 3. Currently, the use of lockManager is tied to the implementation of a certain catalog.Similar to aws-iceberg, we don't actually force the user to use lockManager. The user knows what he's doing when he chooses a catalog. Basically, catalog's author has solved the concurrency problem and the race condition in the code of the catalog that uses lockManager. After all, he wouldn't need to use lockManager if he didn't solve these problems. 4. Regarding the security of lockManager. This is something that should actually be considered within some kind of extension module.For example, iceberg-aws provides some implementations of lockManager, and the security of such lockManager must be considered by them.iceberg-core shouldn't care about such issues. After all, safety standards are not uniform.The details are varied. From what I've seen so far, the opinion of many people in the community is that the lock-manager should be extended and maintained by users if they want it, just like the aws-iceberg module. In iceberg-core, the implementation of lock-manager should only stop at InMemLockManager. But isn't that too little? Wouldn't it be nice to simply extend something like http-lock-manager for users?After all, it's small and doesn't introduce any other dependencies. -- 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: issues-unsubscr...@iceberg.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org For additional commands, e-mail: issues-h...@iceberg.apache.org
