dennishuo commented on code in PR #1135:
URL: https://github.com/apache/polaris/pull/1135#discussion_r1985957696


##########
polaris-core/src/main/java/org/apache/polaris/core/persistence/transactional/TransactionalPersistence.java:
##########
@@ -88,9 +100,214 @@ void runActionInReadTransaction(
    * @return the list of entityActiveKeys for the specified lookup operation
    */
   @Nonnull
-  List<EntityNameLookupRecord> lookupEntityActiveBatch(
+  List<EntityNameLookupRecord> lookupEntityActiveBatchInCurrentTxn(
       @Nonnull PolarisCallContext callCtx, List<PolarisEntitiesActiveKey> 
entityActiveKeys);
 
   /** Rollback the current transaction */
   void rollback();
+
+  //
+  // Every method of BasePersistence will have a related *InCurrentTxn method 
here; the semantics
+  // being that transactional implementations of a PolarisMetaStoreManager may 
choose to
+  // self-manage outer transactions to perform all the persistence calls 
within that provided
+  // transaction, while the basic implementation will only use the "durable in 
a single-shot"
+  // methods from BasePersistence.

Review Comment:
   If we want to reduce the diffs on the existing `PolarisMetaStoreManagerImpl` 
class we could instead invert the semantics, as in unqualified `writeEntity` 
could already always mean "in current transaction" since the current 
implementations all have that semantic, and instead, we introduce the new 
methods in `AtomicPersistence` to have `writeEntityAtomically`, 
`dropEntityAtomically`, etc.
   
   The problem with doing it inverted like that though is that the 
`BasePersistence` methods are automatically the "InCurrentTxn" variants, so a 
subclass that only implements AtomicPersistence would I suppose just throw 
`UnsupportedOperationException` for all the methods from `BasePersistence` 
which kind of defeats the purpose.
   
   Alternatively, the `doFooAtomically` methods could be the methods declared 
in `BasePersistence`.
   
   In general it makes sense to have the "Atomic" operations in the base 
interface and "Transaction" ones in the subinterface, because as 
[AbstractTransactionalPersistence.java](https://github.com/apache/polaris/pull/1135/files#diff-718b00bacadc702326318cb44c43f49659c96f1c6ae86b1267fa6300973e82ae)
 shows, all Transactional implementations can also achieve the semantics of 
"Atomic Persistence", but not all implementations of Atomic Persistence" can 
support transactional styles.



-- 
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]

Reply via email to