Re: Failed transactions

The only remedy against OutOfMemoryError is to restart the system
giving it more RAM, as you suspected.

Even if you had discarded the last transaction, your system would just
sit there waiting to blow up at the next transaction.

Sneer, the current desktop system I am developing, presents a MemMeter
showing how much RAM is being used and what the max is.

You don't necessarily need a visible meter, but it would be wise to
popup messages at certain thresholds.

See you, Klaus.


On Fri, Jul 31, 2009 at 9:44 PM, Ross Rick<[email protected]> wrote:
> Klaus,
>
> I am discussing the likelihood that I will someday be faced with out
> of memory problems and yes, once you've popped your memory, you have
> no idea what your app will do for any given user action, no doubt
> about it.  That is precisely why I am bringing it up, the scenario is
> very real.  My customers will quickly eat up all the memory / data
> space I give them and then demand more.  My responsibility is to do
> the maximum possible to protect my customers data.  At the same time,
> I would like to give them as much speed as possible, hence my being
> here.
>
> If a computer goes down during a db transaction you lose the
> transaction and it is not re-attemped when you come back.  That is a
> perfectly reasonable expectation.   With Prevayler, the failed
> transaction will reattempt unless I tell the system otherwise.
>
> If the last transaction fails due to a lack of available memory,  it
> is reasonable to assume that the same thing could happen if I come
> back up and re-run the transaction.  I am going to have to manage that
> somehow and I ask again, how (if at all) has anyone out there prepared
> for this scenario?   All systems have strengths and weaknesses, and I
> don't mind dealing with prevayler's weaknesses to get it's benefits,
> but I do need to understand them in gory detail.
>
> Thanks,
>
> R
>
> On Jul 31, 2009, at 2:50 PM, Klaus Wuestefeld wrote:
>
>> There is a more general question that you have to answer anyway,
>> regardless of how you do your persistence, Prevayler or otherwise:
>>
>> "My system is in a state that will crash given some common basic user
>> action. What now?"
>>
>> See you, Klaus.
>>
>>
>>
>> On Fri, Jul 31, 2009 at 5:28 PM, Ross Rick<[email protected]> wrote:
>>> If read the previous thread correctly...   a transaction is
>>> journaled to the
>>> disk prior to execution on the model.
>>> If the transaction fails, does the journaled transaction always get
>>> removed
>>> from disk?   It would appear that the transaction is removed from
>>> disk under
>>> normal circumstances, but under catastrophic failure, it's less
>>> clear.
>>> In fact, I doubt that it is entirely possible to ensure any such
>>> thing.
>>> How do the rest of you handle this?   When you come back up your
>>> system will
>>> attempt the transaction again, even if it works, that is not the
>>> expected
>>> state of the system.   The expected state is the state just prior to
>>> attempting the bad transaction.
>>> How am I doing on the understanding here?   I appreciate everyone's
>>> help
>>> very much.
>>>
>>> R
>>> ------------------------------------------------------------------------------
>>> Let Crystal Reports handle the reporting - Free Crystal Reports
>>> 2008 30-Day
>>> trial. Simplify your report design, integration and deployment -
>>> and focus
>>> on
>>> what you do best, core application coding. Discover what's new with
>>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>>> _______________________________________________
>>> To unsubscribe go to the end of this page:
>>> http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
>>> _______________________________________________
>>> "Databases in Memoriam" -- http://www.prevayler.org
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> 30-Day
>> trial. Simplify your report design, integration and deployment - and
>> focus on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
>> _______________________________________________
>> "Databases in Memoriam" -- http://www.prevayler.org
>>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
> _______________________________________________
> "Databases in Memoriam" -- http://www.prevayler.org
>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
_______________________________________________
"Databases in Memoriam" -- http://www.prevayler.org