Re: reads which modify data

you are right, no need to wrap reads in queries and hence we dont do
that. that's why i said reads, not queries ;)

your suggestion to create transactions for "read triggered
modifications" will work. but there is a tradeoff: my core classes
dont know anything about prevayler and i prefer they stay so. so they
should notify some other "prevayler aware" piece of code, which will
apply the "random modification" in a transaction. we also need some
public methods like "break the engine", "cut off the wing" in core
classes accesible from "prevayler layer". a possible point break of
internal consistency

on the otherside my "dummy read transactions" requires same seed and
random sequence to work

it's just a matter of taste i guess..

cheers
r a f t

On Tue, Mar 3, 2009 at 9:31 AM,  <[email protected]> wrote:
> I may be a bit off here, but you say "each read and write are synchronized
> in game".
>
> Why not just read the data from the entity, and:
> - If it "wants" to modify something, create a transaction that does that.
> - Otherwise rock on.
>
> If the reads and writes are synchronized, there's no need to even wrap the
> reads in queries. Just read right away from the model.
>
> I also presume that it would be irrelevant if the seed number changes
> after a system restore, since all past modifications will be the same, and
> the future will be "random". Is this not the case?
>
> What am _I_ missing? :-)
>
> /Mikael
> - Show quoted text -
>> right, this solves the "what was the seed" question but we still
>> suffer performace decrease and exactness..
>>
>> i've found a solution like this:
>>
>> game will be created with a random with some seed. when a random event
>> occurs within a read, it will get next random value from game's random
>> source. then a dummy transaction will be created which will read
>> entity's property. during recovery this will create same random
>> sequence since:
>>
>> * for some other reason, each read and write are syncronized on game
>> * game and prevayler's clock is paused at the beginning of each read and
>> write
>> * prevayler guarantees transaction ordering
>>
>> so during recovery we will get same sequence of modifying reads with
>> same transaction (hence random number) sequence
>>
>> a bit complicated but only solution i have found since now
>>
>> regards,
>> r a f t
>>
>> On Mon, Mar 2, 2009 at 9:35 PM, Klaus Wuestefeld
>> <[email protected]> wrote:
>>> The solution described by Edward of having a tick is good. Only the
>>> ticks will update state, not the queries.
>>>
>>> You dont need to have one transaction per tick. You execute them
>>> lazily, right before every query or transaction:
>>>
>>>   synchronized (system) {
>>>      if ( ! areAllTicksProcessedTill(time))
>>>         processAllTicksTill(time)
>>>   }
>>>
>>>
>>>
>>>> we cannot depend on any pre-seeded sequence
>>>> since this is a read and there is no guarantee it will occur again in
>>>> same order.
>>>
>>> With the ticks solution you can guarantee there will be exactly one
>>> tick per logical millisecond and exactly the same number of random
>>> values will be consumed every time you rerun the same simulation with
>>> the same transactions.
>>>
>>> You just have to make sure Prevayler's clock and your simulation clock
>>> are consistent.
>>>
>>> That is pretty easy since you can configure the clock that Prevayler
>>> uses. :)
>>>
>>> See you, Klaus.
>>>
>>>
>>> On Mon, Mar 2, 2009 at 10:12 AM, Edward Kimber <[email protected]>
>>> wrote:
>>>> This sounds like some sort of simulation...
>>>> I would think about having a system clock that triggers a model
>>>> update/recalculation on every tick.  This system can include your
>>>> seeded pseudo-random elements and also be deterministic.  You can then
>>>> allow very fast direct access reads and you don't need to worry about
>>>> the write operation because all model updates will be performed by the
>>>> 'tick' transaction.
>>>> Just an idea. :)
>>>> Ed
>>>>
>>>> 2009/3/2 hakan eryargi <[email protected]>:
>>>>> ok, this is what i do without the (pseudo)random part: "lazy
>>>>> evaluation"
>>>>>
>>>>> for the random part, the problem is how to find a random seed that we
>>>>> can later find again and use. using same seed is a solution but of
>>>>> course we dont want that. we are in the middle of a read operation
>>>>> came from some client at some -truly- random time. so we cant use
>>>>> executionTime as a seed. we cannot depend on any pre-seeded sequence
>>>>> since this is a read and there is no guarantee it will occur again in
>>>>> same order.
>>>>>
>>>>> am i missing something ?
>>>>>
>>>>> On Mon, Mar 2, 2009 at 6:38 AM, Klaus Wuestefeld
>>>>> <[email protected]> wrote:
>>>>>> Stop thinking in terms of "reads which modify data" and think about
>>>>>> it
>>>>>> as "lazy evaluation", which is perfectly ok. Something like this:
>>>>>>
>>>>>>
>>>>>> Object executeQuery(Date executionTime) {
>>>>>>
>>>>>>   synchronized (_system) {
>>>>>>      if (!isStateUpdatedTo(executionTime))
>>>>>>
>>>>>> updateStateWithReallyComplexAndPseudoRandomRulesTo(executionTime);
>>>>>>   }
>>>>>>
>>>>>>   return queryStateWhatever();
>>>>>> }
>>>>>>
>>>>>>
>>>>>> See you, Klaus.
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San
>>>>>> Francisco, CA
>>>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the
>>>>>> Enterprise
>>>>>> -Strategies to boost innovation and cut costs with open source
>>>>>> participation
>>>>>> -Receive a $600 discount off the registration fee with the source
>>>>>> code: SFAD
>>>>>> http://p.sf.net/sfu/XcvMzF8H
>>>>>> _______________________________________________
>>>>>> To unsubscribe go to the end of this page:
>>>>>> http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
>>>>>> _______________________________________________
>>>>>> "Databases in Memoriam" -- http://www.prevayler.org
>>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San
>>>>> Francisco, CA
>>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the
>>>>> Enterprise
>>>>> -Strategies to boost innovation and cut costs with open source
>>>>> participation
>>>>> -Receive a $600 discount off the registration fee with the source
>>>>> code: SFAD
>>>>> http://p.sf.net/sfu/XcvMzF8H
>>>>> _______________________________________________
>>>>> To unsubscribe go to the end of this page:
>>>>> http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
>>>>> _______________________________________________
>>>>> "Databases in Memoriam" -- http://www.prevayler.org
>>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San
>>>> Francisco, CA
>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the
>>>> Enterprise
>>>> -Strategies to boost innovation and cut costs with open source
>>>> participation
>>>> -Receive a $600 discount off the registration fee with the source code:
>>>> SFAD
>>>> http://p.sf.net/sfu/XcvMzF8H
>>>> _______________________________________________
>>>> To unsubscribe go to the end of this page:
>>>> http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
>>>> _______________________________________________
>>>> "Databases in Memoriam" -- http://www.prevayler.org
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Open Source Business Conference (OSBC), March 24-25, 2009, San
>>> Francisco, CA
>>> -OSBC tackles the biggest issue in open source: Open Sourcing the
>>> Enterprise
>>> -Strategies to boost innovation and cut costs with open source
>>> participation
>>> -Receive a $600 discount off the registration fee with the source code:
>>> SFAD
>>> http://p.sf.net/sfu/XcvMzF8H
>>> _______________________________________________
>>> To unsubscribe go to the end of this page:
>>> http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
>>> _______________________________________________
>>> "Databases in Memoriam" -- http://www.prevayler.org
>>>
>>
>> ------------------------------------------------------------------------------
>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco,
>> CA
>> -OSBC tackles the biggest issue in open source: Open Sourcing the
>> Enterprise
>> -Strategies to boost innovation and cut costs with open source
>> participation
>> -Receive a $600 discount off the registration fee with the source code:
>> SFAD
>> http://p.sf.net/sfu/XcvMzF8H
>> _______________________________________________
>> To unsubscribe go to the end of this page:
>> http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
>> _______________________________________________
>> "Databases in Memoriam" -- http://www.prevayler.org
>>
>
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
> _______________________________________________
> "Databases in Memoriam" -- http://www.prevayler.org
>

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
_______________________________________________
"Databases in Memoriam" -- http://www.prevayler.org