[Prevayler-coders] Re: Configurable Transaction Pipeline (was Re: StrictTransactionCensor)

[Bill B. <bi...@mo...>]

What I meant by 'skip' was to proceed even though there was an 
exception, instead of crashing.


Klaus Wuestefeld wrote:

>On 7/1/05, Bill Burdick <bi...@mo...> wrote:
>  
>
>>I think we are using prevayler in a different way from normal.
>>    
>>
>
>There are many different ways in which people use Prevayler. It is
>hard to say what is normal.  :)
>
>  
>
>>Our apps
>>change data outside prevayler's control and only store data in the
>>prevalent system as clones, so outside changes do not affect the state
>>of the system.  We aren't using POJOs; we are using our own model that
>>is similar to Java Beans or JDO in some ways, so that cloning can be
>>intelligently managed by the system.  Thus, we have a very small, closed
>>set of prevayler commands (domain apps don't extend the set).  If there
>>is a failure in a prevayler command, it means that our framework has an
>>error (not the domain code).  In this case, the program needs to crash
>>and it is important (in our case) that the command not be written to the
>>log.
>>    
>>
>
>An interesting approach for Prevayler3 might be to make the
>transaction execution pipeline configurable, so people can decide what
>to do and when.
>
>  
>
>>Here's something I just thought of.  Suppose a prevalent system has been
>>in use for some time and there is a code upgrade.  When the new system
>>starts up, one of the transactions fails during replay because of a new
>>error in the system.  Is it a good idea to crash or to continue,
>>skipping over the newly failed transaction?
>>    
>>
>
>You cannot simply "skip" a transaction. Your system will become inconsistent.
>
>It is good practice to take a snapshot immediately before deploying a
>new version of the system.
>
>See you, Klaus.
>
>  
>
>>Klaus Wuestefeld wrote:
>>
>>    
>>
>>>>Perhaps it could be a factory option?
>>>>
>>>>
>>>>        
>>>>
>>>Could be.
>>>
>>>Do you realize the user will be able to see the results of the
>>>inconsistent transaction in the prevalent system?
>>>
>>>See you, Klaus.
>>>
>>>
>>>
>>>
>>>      
>>>
>>>>Klaus Wuestefeld wrote:
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>Hi Bill,
>>>>>
>>>>>I was in Germany for a couple of weeks.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>Is the only purpose of the StrictTransactionCensor to execute commands
>>>>>>on a copy of the system in order to avoid writing erroneous transactions
>>>>>>to the log?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>It also avoids executing erroneous transactions on the "real" system.
>>>>>
>>>>>Do you think that is not necessary?
>>>>>
>>>>>See you, Klaus.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>If so, I think it would be lot more efficient to eliminate transaction
>>>>>>censors and change
>>>>>>CentralPublisher.publishWithoutWorryingAboutNewSubscriptions() by
>>>>>>replacing the approve, log, notify lines with this:
>>>>>>
>>>>>>_logger.serializeTransaction(transaction, executionTime, myTurn,
>>>>>>serializationBuffer);
>>>>>>notifySubscribers(...);
>>>>>>_logger.logSerialization(serializationBuffer);
>>>>>>
>>>>>>
>>>>>>This way, you still save the state of the command before execution, but
>>>>>>if execution throws an exception, the command does not get written out.
>>>>>>
>>>>>>serializationBuffer is an instance variable storing a
>>>>>>ByteArrayOutputStream.  serializeTransaction() resets the buffer before
>>>>>>serialization and logSerialization() uses ByteArrayOutputStream.writeTo().
>>>>>>
>>>>>>--
>>>>>>      Bill Burdick
>>>>>>      Bi...@mo...
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>--
>>>>       Bill Burdick
>>>>       Bi...@mo...
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>
>>>      
>>>
>>--
>>        Bill Burdick
>>        Bi...@mo...
>>
>>
>>    
>>
>
>  
>


-- 
	Bill Burdick
	Bi...@mo...