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

Dale Henrichs via Glass glass at lists.gemtalksystems.com
Thu Feb 9 08:21:58 PST 2017



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 
> <mailto: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.

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

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

Dale


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20170209/23fb4892/attachment.html>


More information about the Glass mailing list