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

[Mariano Martinez Peck via Glass]

On Thu, Feb 9, 2017 at 1:21 PM, Dale Henrichs <
dale.henrichs at gemtalksystems.com> wrote:

>
>
> On 02/09/2017 04:27 AM, Mariano Martinez Peck wrote:
>
>
>
> 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 ... 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 .... 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:)
>>
>
>
> Hi Dale,
>
> What is the status of this not-tranlogged data? My question is because I
> have some cron jobs that run at night, some processing text files and
> filling some data. These processes are generating 13GB of tranglos every
> day..
>
> Thanks!
>
>
>
> I haven't done anymore work on not-tranlogged data since that message ...
> Whether or not not-tranlogged data can reduce the size of your tranlogs
> depends upon the nature of your cron jobs ...
>
> If you are using Seaside for the batch jobs and the bulk of the data
> dumped into the tranlogs is seaside session state, then the work that I've
> done previously might be able to reduce the load.
>


No, no Seaside sessions involved at all.


>
> If you are not using Seaside, you still might be able to reduce the size
> of your tranlogs with not-tranlogged _if_ you happen to be persisting a lot
> of intermediate results that do not survive in the final result (large
> strings from files for example or large XML data structures, or ???)... If
> the stone crashes while doing batch processing and your strategy is to
> rerun the batch jobs after a crash, then it might make sense to use
> not-tranlogged data for your intermediate results ...
>

Yes, exactly, if the stone crashes, I don't care to recover these data. I
would simply re-run the job.


>
> It is relatively straightforward to start using not-tranlogged data, you
> basically root the objects in NotTranloggedGlobals and follow the rules:
> not-tranlogged objects can reference tranlogged objects, but tranlogged
> objects cannot reference not-tranlogged objects. If you have a high volume
> of intermediate objects that do not survive after the batch job then you
> should see a reduction in tranlog size ...
>
>

OK, thanks for the explanation. I will see if I can play a bit with this.



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