Re: Failed transactions

Hi.

I would just like to give my view of this.

Let's assume we have perfectly fine transactions without bugs causing OOM.
(This is theory, ok? ;-)

What makes you think the last transaction is "bad"? Is it wrong because it
happend to cause the OOM error?
In my view it's just as valid as all previous transactions. Why would you
remove it?

As Justin said, Prevayler will not proceed if you get the OOM error, so no
need to worry about an inconsistent state of the model.

If it continues to blow up when restoring the model, then you have
insufficient ram to run your program.

Have I misunderstood?

/Mikael

> As expected.   I wonder that no has quibbled about this before, as it
> is very surprising that the transaction is still there and will run.
> But hardly an insurmountable problem.
>
> Looks like I'm going into the JMX stuff, unless you happen to be
> working on an open source project right now?
>
> R
>
> On Jul 31, 2009, at 7:09 PM, Klaus Wuestefeld wrote:
>
>> 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
>>
>
>
> ------------------------------------------------------------------------------
> 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