"K.S. Bhaskar" <ksbhaskar@[EMAIL PROTECTED]
> wrote in message
news:770d2c0c-8186-422b-92a4-3805e4515c22@[EMAIL PROTECTED]
> On Dec 20, 8:12 pm, "Chip Humphreys" <cbh...@[EMAIL PROTECTED]
> wrote:
>> > IMHO, I personally think this is a step backwards, but then again who
>> > am I
>> > to say what is good and what is bad...I'm just the end user.
>>
>> It is not really a step back it is in fact a step in the right
direction.
>> Under Cache 5.0 you had to specify either ALL or Selected Globals.
Which
>> meant if you wanted to exclude you had to specify all the globals you
>> wanted
>> to journal, which in a production system is a real pain, or you journal
>> everything.
>> Now under Cache 5.2 you journal all the globals in a DB and if you want
>> certain globals to not be journals you set them up in a separate DB,
>> using
>> global mapping, and do not journal that DB. This actually makes a lot
>> more
>> sense since most production systems will want to journal most of the
>> globals
>> with the non-journled globals being the exception.
>>
>> So we have gone from "tell me what you want to journal and I will not
>> journal the rest" to "tell me what you do not want to journal and I
will
>> journal the rest". Which IMHO is a far better premise to start with
>
> [KSB] I agree with Chip. That is the better philosophy. Not
> journaling is the right solution only for (a) read-only data - which
> won't get journaled anyway, if they don't change, and (b) transient
> data such as process ids and partial result sets that would get
> discarded when the system is rebooted. Any data you care about should
> be journaled, and good design philosophies encourage users to do the
> right thing.
>
> Regards
> -- Bhaskar
I agree that you normally have more globals that you want to journal than
those that you don't, I just think it is easier to add to a list those
globals that you don't want to journal than having to set up an additional
database for those globals you don't want to journal.
Mike
|
