[Glass] Is it possible to disable tranlogs for some gems?

[Mariano Martinez Peck via Glass]

On Mon, Aug 31, 2015 at 12:32 PM, Dale Henrichs via Glass <
glass at lists.gemtalksystems.com> wrote:

> Yeah, you have to stop the stone, change configs, start stone, do bulk
> load, stop stone, reset configs and the restart stones ... should disable
> customer access during that time as well ...
>

Yeah, indeed. Seems messy.... Probably not worth.


> there is a not-tranlogged data feature but that is a case where persistent
> data is not tranlogged and is not recoverable on a crash, but in this case
> you lose the ability to recover the persistent state altogether on a crash
> ... which is probably not appropriate in your case ....
>

Well, I think this IS my case. I mean, I do not care if a crash happens
while I am not tran-logging the persistent objects from these bulk
processes since these can be re-executed without problem. I mean these
processes take for example huge csv files, parse them and persist. So if
there is a system crash and I lost the data I persisted in those jobs (I do
not loose data I persisted via seaside gems right?), then no problem, I can
easily run the jobs again once the stone is restored :)


> I am hoping to get the not-tranlogged feature hooked up for Seaside3.2 and
> GemStone3.3, but that is a pipe dream at this point:)
>
>
hehehhe I understand.

Haven't you ever have the need of a not-tranlogged feature at a gem level?
Say...everything from this gem, do not need to be logged? I know... I can
imagine that at the repository/stone level and tranlogs level you know
nothing about the gems right?

Anyway..thanks for the answer!


> Dale
>
>
> On 8/31/15 8:13 AM, Mariano Martinez Peck via Glass wrote:
>
> OK the admin guide proposes to like:
>
> STN_TRAN_LOG_DIRECTORIES = /dev/null, /dev/null;
> STN_TRAN_FULL_LOGGING = TRUE;
>
> But that still implies files modification and stone stop/start right? At
> least I do not need to make a full backup? mmm sounds like....they forgot
> to say that there?
>
>
>
> On Mon, Aug 31, 2015 at 12:04 PM, Mariano Martinez Peck <
> <marianopeck at gmail.com>marianopeck at gmail.com> wrote:
>
>> Hi guys,
>>
>> I almost sure the answer is no. But I would like to comment my scenario
>> since there could be other workarounds. I have some daily cron jobs that
>> run at night that do quite large commits. Basically, they read huge files
>> and do a kind of bulk load into GemStone.
>>
>> Once of the things I notice is that for every day, I have like 4 log
>> files of 1GB each. This makes much more space usage on disk (which in my
>> case is importante) and also, I can imagine there is quite a performance
>> downgrade while having to write logs.
>>
>> So since this jobs run at night, with little or none user connect, I am
>> fine with not writing logs while these jobs run. "I am fine" in the sense
>> that if the system crashes while doing so, I am ok to recover from previous
>> checkpoint and lost a few transactions if any.
>>
>> However, it seems it is not possible to disable tranlogs for particular
>> gems, right? In addition, I did not found an easy way to directly
>> enable/disable logs of the stone. To disable, the admin guide says I must
>> run a full backup, then change file, then stop stone, start again etc...So
>> it seems quite complicated...
>>
>> Is there anything that could help me here?
>>
>> I am using GemStone 3.1.0.6
>>
>> Thanks in advance,
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>
> _______________________________________________
> Glass mailing listGlass at lists.gemtalksystems.comhttp://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150831/15c5822a/attachment.html>