Re: Failed transactions

As discussed in an earlier thread, we have a couple different error  
scenarios..  OOM is serious and may require manual intervention.  Ok.  
fine.

The other types, "deterministic" are like when a parameter that must  
be validated at transaction time fails.  Existence of a dependent  
object for example.  I have to test within the execution of  
transaction to guarantee state.   When that fails, I wonder what the  
expected state of the journal is.

R


On Aug 1, 2009, at 4:02 PM, [email protected] wrote:

> 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


------------------------------------------------------------------------------
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