reads which modify data
|
View:
New views
19 Messages
—
Rating Filter:
Alert me
|
 |
reads which modify data
by raft
::
Rate this Message:
hello,
how would you design a system where some reads modify the data in an undeterministic way ? undeterministic means random here and can be translated into a deterministic one by supplying random seed from outside. one can say, these are actually writes not reads, so must be handled as transactions. the answer is there are so many of them so we cannot simply afford handling them as transactions. and a very very little proportion of that reads cause such random modifications. these reads trigger lazy calculations as described in this thread: http://www.nabble.com/Re%3A-execution-order-of-queries-and-transactions-p17049169.html continuing the sample in that thread: think of a moving entity. a write operation modifies its acceleration and direction, read operation calculates current velocity and position and returns them. no matter how many times you read the velocity, it will be the same at some specific point in time. it's ok till now. now add another feature that when entity's velocity drops to zero it takes some random damage. so when velocity or position is read, there is a chance that this will trigger a damage. how would you persist such a system with prevayler ? regards, r a f t ------------------------------------------------------------------------------ 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 |
|
|
Re: reads which modify data
by Justin T. Sampson-2
::
Rate this Message:
To take your example literally, why wouldn't you apply the random damage during the write operation, at the moment the velocity drops to zero?
-Justin On Sun, Mar 1, 2009 at 5:48 AM, hakan eryargi <hakan.eryargi@...> wrote: hello, -- Agile Focus - http://agilefocus.com/ ------------------------------------------------------------------------------ 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 |
|
|
Re: reads which modify data
by Klaus Wuestefeld
::
Rate this Message:
You described the solution yourself:
Make the randomness pseudo-random using a seed. So now you are simply doing lazy-eval in your queries, which is ok. You just have to manually sync that, of course, which sounds simple to do in your case. What am I missing? On Sun, Mar 1, 2009 at 1:03 PM, Justin T. Sampson <justin@...> wrote: > To take your example literally, why wouldn't you apply the random damage > during the write operation, at the moment the velocity drops to zero? > > -Justin > > > On Sun, Mar 1, 2009 at 5:48 AM, hakan eryargi <hakan.eryargi@...> > wrote: >> >> hello, >> >> how would you design a system where some reads modify the data in an >> undeterministic way ? undeterministic means random here and can be >> translated into a deterministic one by supplying random seed from >> outside. >> >> one can say, these are actually writes not reads, so must be handled >> as transactions. the answer is there are so many of them so we cannot >> simply afford handling them as transactions. and a very very little >> proportion of that reads cause such random modifications. >> >> these reads trigger lazy calculations as described in this thread: >> >> http://www.nabble.com/Re%3A-execution-order-of-queries-and-transactions-p17049169.html >> >> continuing the sample in that thread: think of a moving entity. a >> write operation modifies its acceleration and direction, read >> operation calculates current velocity and position and returns them. >> no matter how many times you read the velocity, it will be the same at >> some specific point in time. it's ok till now. now add another >> feature that when entity's velocity drops to zero it takes some random >> damage. so when velocity or position is read, there is a chance that >> this will trigger a damage. >> >> how would you persist such a system with prevayler ? >> >> regards, >> r a f t >> >> >> ------------------------------------------------------------------------------ >> 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 > > > > -- > Agile Focus - http://agilefocus.com/ > > ------------------------------------------------------------------------------ > 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 |
|
|
Re: reads which modify data
by raft
::
Rate this Message:
i can do that only if i know when velocity will drop to zero
beforehand: schedule a task for that time, which calculates the random damage and applies it in a transaction. for this example it's easy, requires only solving a 1st level - one variable equation. but for a sligtly more complex system (a 2nd or 3rd level equation for instance) such points cannot easily be calculated beforehand. or is it something else you meant ? r a f t On Sun, Mar 1, 2009 at 6:03 PM, Justin T. Sampson <justin@...> wrote: > To take your example literally, why wouldn't you apply the random damage > during the write operation, at the moment the velocity drops to zero? > > -Justin > > > On Sun, Mar 1, 2009 at 5:48 AM, hakan eryargi <hakan.eryargi@...> > wrote: >> >> hello, >> >> how would you design a system where some reads modify the data in an >> undeterministic way ? undeterministic means random here and can be >> translated into a deterministic one by supplying random seed from >> outside. >> >> one can say, these are actually writes not reads, so must be handled >> as transactions. the answer is there are so many of them so we cannot >> simply afford handling them as transactions. and a very very little >> proportion of that reads cause such random modifications. >> >> these reads trigger lazy calculations as described in this thread: >> >> http://www.nabble.com/Re%3A-execution-order-of-queries-and-transactions-p17049169.html >> >> continuing the sample in that thread: think of a moving entity. a >> write operation modifies its acceleration and direction, read >> operation calculates current velocity and position and returns them. >> no matter how many times you read the velocity, it will be the same at >> some specific point in time. it's ok till now. now add another >> feature that when entity's velocity drops to zero it takes some random >> damage. so when velocity or position is read, there is a chance that >> this will trigger a damage. >> >> how would you persist such a system with prevayler ? >> >> regards, >> r a f t >> >> >> ------------------------------------------------------------------------------ >> 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 > > > > -- > Agile Focus - http://agilefocus.com/ > > ------------------------------------------------------------------------------ > 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 |
|
|
Re: reads which modify data
by raft
::
Rate this Message:
can you explain what you mean by manually synching ?
r a f t On Sun, Mar 1, 2009 at 11:11 PM, Klaus Wuestefeld <klauswuestefeld@...> wrote: > You described the solution yourself: > > Make the randomness pseudo-random using a seed. So now you are simply > doing lazy-eval in your queries, which is ok. You just have to > manually sync that, of course, which sounds simple to do in your case. > > What am I missing? > > > > On Sun, Mar 1, 2009 at 1:03 PM, Justin T. Sampson <justin@...> wrote: >> To take your example literally, why wouldn't you apply the random damage >> during the write operation, at the moment the velocity drops to zero? >> >> -Justin >> >> >> On Sun, Mar 1, 2009 at 5:48 AM, hakan eryargi <hakan.eryargi@...> >> wrote: >>> >>> hello, >>> >>> how would you design a system where some reads modify the data in an >>> undeterministic way ? undeterministic means random here and can be >>> translated into a deterministic one by supplying random seed from >>> outside. >>> >>> one can say, these are actually writes not reads, so must be handled >>> as transactions. the answer is there are so many of them so we cannot >>> simply afford handling them as transactions. and a very very little >>> proportion of that reads cause such random modifications. >>> >>> these reads trigger lazy calculations as described in this thread: >>> >>> http://www.nabble.com/Re%3A-execution-order-of-queries-and-transactions-p17049169.html >>> >>> continuing the sample in that thread: think of a moving entity. a >>> write operation modifies its acceleration and direction, read >>> operation calculates current velocity and position and returns them. >>> no matter how many times you read the velocity, it will be the same at >>> some specific point in time. it's ok till now. now add another >>> feature that when entity's velocity drops to zero it takes some random >>> damage. so when velocity or position is read, there is a chance that >>> this will trigger a damage. >>> >>> how would you persist such a system with prevayler ? >>> >>> regards, >>> r a f t >>> >>> >>> ------------------------------------------------------------------------------ >>> 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 >> >> >> >> -- >> Agile Focus - http://agilefocus.com/ >> >> ------------------------------------------------------------------------------ >> 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 |
|
|
Re: reads which modify data
by Klaus Wuestefeld
::
Rate this Message:
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 |
|
|
Re: reads which modify data
by raft
::
Rate this Message:
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 <klauswuestefeld@...> 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 |
|
|
Re: reads which modify data
by Edward Kimber
::
Rate this Message:
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 <hakan.eryargi@...>: > 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 > <klauswuestefeld@...> 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 |
|
|
Re: reads which modify data
by Klaus Wuestefeld
::
Rate this Message:
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 <edward.kimber@...> 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 <hakan.eryargi@...>: >> 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 >> <klauswuestefeld@...> 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 |
|
|
Re: reads which modify data
by raft
::
Rate this Message:
this will work. but this is not lazy evaluation.
we chosed lazy evaluation to make updates only when necessary (save cpu power) and get exact results whenever read. in our sample, if one asks an entity its speed just between two ticks, the returned result will not be exact. the smaller you make the ticks the more you need processing power. On Mon, Mar 2, 2009 at 3:12 PM, Edward Kimber <edward.kimber@...> 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 <hakan.eryargi@...>: >> 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 >> <klauswuestefeld@...> 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 |
|
|
Re: reads which modify data
by raft
::
Rate this Message:
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 <klauswuestefeld@...> 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 <edward.kimber@...> 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 <hakan.eryargi@...>: >>> 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 >>> <klauswuestefeld@...> 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 |
|
|
Java5 branch status
by Matthew Bishop
::
Rate this Message:
I'm a big fan of the generics features of java5 and I wanted to have a
look at this branch. Any caveats or known issues? On Mar 2, 2009, at 12:09 PM, hakan eryargi <hakan.eryargi@...> wrote: ------------------------------------------------------------------------------ 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 |
|
|
Re: Java5 branch status
by Justin T. Sampson-2
::
Rate this Message:
The internals are pretty much unchanged, so it should all work fine. I tried pretty hard to keep backward-compatible interfaces. There are some enhancements that I plan to merge into the master branch at some point; you may or may not notice them.
I ended up somewhat disillusioned about using generics for everything. I developed and deployed an application with it myself, kind of as an experiment (the application was real, using generics was an experiment), but wasn't satisfied enough to release it. There are certain things that are very nice about generics, but they can also become kind of viral and verbose. I'd be curious to hear your impressions if you try it out. Cheers, Justin
On Mon, Mar 2, 2009 at 4:36 PM, Matthew Bishop <matt@...> wrote: I'm a big fan of the generics features of java5 and I wanted to have a -- Agile Focus - http://agilefocus.com/ ------------------------------------------------------------------------------ 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 |
|
|
Re: Java5 branch status
by Matthew Bishop
::
Rate this Message:
I'll check it out and give it a go. -- Matt Bishop
------------------------------------------------------------------------------ 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 |
|
|
Re: reads which modify data
by mikael-12
::
Rate this Message:
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 > 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 > <klauswuestefeld@...> 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 <edward.kimber@...> >> 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 <hakan.eryargi@...>: >>>> 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 >>>> <klauswuestefeld@...> 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 |
|
|
Re: reads which modify data
by raft
::
Rate this Message:
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, <mikael@...> 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 >> <klauswuestefeld@...> 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 <edward.kimber@...> >>> 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 <hakan.eryargi@...>: >>>>> 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 >>>>> <klauswuestefeld@...> 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 |
|
|
Re: reads which modify data
by mikael-12
::
Rate this Message:
Without further thought, an idea that comes to mind is to use an aspect
framework to intercept modifications and execute transactions. > 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, <mikael@...> 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 >>> <klauswuestefeld@...> 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 >>>> <edward.kimber@...> >>>> 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 <hakan.eryargi@...>: >>>>>> 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 >>>>>> <klauswuestefeld@...> 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 > ------------------------------------------------------------------------------ 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 |
|
|
Re: Java5 branch status
by Matthew Bishop
::
Rate this Message:
I have lost my link to where to check out this branch. Where should I
go to checkout this branch? Thanks, Matt On Mar 2, 2009, at 5:49 PM, Justin T. Sampson wrote: > The internals are pretty much unchanged, so it should all work fine. > I tried pretty hard to keep backward-compatible interfaces. There > are some enhancements that I plan to merge into the master branch at > some point; you may or may not notice them. > > I ended up somewhat disillusioned about using generics for > everything. I developed and deployed an application with it myself, > kind of as an experiment (the application was real, using generics > was an experiment), but wasn't satisfied enough to release it. > > There are certain things that are very nice about generics, but they > can also become kind of viral and verbose. I'd be curious to hear > your impressions if you try it out. > > Cheers, > Justin > > > On Mon, Mar 2, 2009 at 4:36 PM, Matthew Bishop <matt@...> > wrote: > I'm a big fan of the generics features of java5 and I wanted to have a > look at this branch. Any caveats or known issues? > > > -- > Agile Focus - http://agilefocus.com/ > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion _______________________________________________ "Databases in Memoriam" -- http://www.prevayler.org |
|
|
Re: Java5 branch status
by Justin T. Sampson-2
::
Rate this Message:
The Prevayler repository is now hosted on GitHub:
http://github.com/jsampson/prevayler The branch in question is "java5_experiment": http://github.com/jsampson/prevayler/tree/java5_experiment Cheers, Justin On Wed, Mar 11, 2009 at 1:07 PM, Matthew Bishop <matt@...> wrote: I have lost my link to where to check out this branch. Where should I -- Agile Focus - http://agilefocus.com/ ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion _______________________________________________ "Databases in Memoriam" -- http://www.prevayler.org |
| Free embeddable forum powered by Nabble | Forum Help |
