Re: JournalDiskSyncStrategy?

By the way, I have no clue how to write a test case for this new code. 

I'm all ears if someone has a clue.


On 12 Aug 2014, at 19:48, Karl Wettin <[email protected]> wrote:

> My suggestion:
> 
> https://github.com/jsampson/prevayler/pull/9
> 
> On 11 Aug 2014, at 21:53, Justin Sampson <[email protected]> wrote:
> 
>> Karl Wettin wrote:
>> 
>>> What I do is to place a transient object graph of a given root
>>> object on a queue which is polled by a single thread which
>>> evaluate the delta which produce and execute transactions.
>>> Sometimes as many as 200 transaction from a single delta. 
>>> 
>>> Usually I manage to empty this queue a every few seconds when
>>> not syncing on each transaction. It would be nice to sync at
>>> that point.
>>> 
>>> Running FS.sync on each and every transaction produced from the
>>> delta of a transient root object graph takes up to 10 seconds
>>> on my slow HDD, usually 5-7, while not syncing takes 1-3
>>> milliseconds.
>> 
>> Oh, interesting. Prevayler tries to batch multiple transactions
>> into a single disk sync, but the current implementation is
>> thread-based: The number of transactions per batch is bounded by
>> the number of threads that are submitting transactions. You
>> probably don't want to create 200 threads just to submit those
>> 200 transactions.
>> 
>> If the Prevayler interface were redesigned to be asynchronous,
>> you could submit all 200 transactions without waiting for them to
>> complete, and Prevayler could take care of batching them for you.
>> Unfortunately that would require some nontrivial redesign of
>> Prevayler's internals.
>> 
>> A less drastic change would be to add a single new method to the
>> Prevayler interface, e.g.:
>> 
>> void executeAll(Iterable<? extends Transaction<? super P>>)
>> 
>> The implementation could then ensure that all of the given
>> transactions get batched into a single disk sync.
>> 
>> For that matter, even without any changes to Prevayler, you could
>> combine your 200 individual transactions into a single composite
>> transaction with the same effect, e.g.:
>> 
>> public final class CompositeTransaction<P>
>>   implements Transaction<P>, Serializable {
>> private final List<Transaction<P>> transactions;
>> public CompositeTransaction(
>>     Collection<? extends Transaction<P>> transactions) {
>>   this.transactions = new ArrayList<>(transactions);
>> }
>> public void executeOn(P prevalentSystem, Date executionTime) {
>>   for (Transaction<P> transaction : transactions) {
>>     transaction.executeOn(prevalentSystem, executionTime);
>>   }
>> }
>> }
>> 
>> Since you're not actually wanting to turn off disk sync, just
>> make it more efficient, one of these options might be preferable
>> to making the disk sync logic itself more configurable.
>> 
>> Cheers,
>> Justin
>> 
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
>> _______________________________________________
>> "Databases in Memoriam" -- http://www.prevayler.org
> 


------------------------------------------------------------------------------
_______________________________________________
To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
_______________________________________________
"Databases in Memoriam" -- http://www.prevayler.org