The Gang

Brian Robinson will be discussing JBPM workflows as applied to Alfresco Document and Web Content Management tomorrow Friday, January 23rd at 5:00pm UTC/GMT, 12:00pm EST, 9:00am PST.

Join us at: http://alfresco.acrobat.com/live

The meeting room will open about 15 minutes prior to the scheduled start time.

Learn more at: http://wiki.alfresco.com/wiki/Live

Posted in Uncategorized | No Comments »

File System Receivers and ACIDity

October 15th, 2008 . by Peter Monks

Over the last week or so we’ve been having an interesting discussion on one of our internal mailing lists about File System Receivers (FSRs) and ACID transactions, and I thought it was worth sharing.

The question that was originally posed was quite simple:

If I have a web site where pages are typically made up of multiple assets, isn’t it possible that for a split second during FSR deployment there will be a window in which not all of those assets will be available, as they may not have been copied from the Alfresco WCM authoring environment yet?
(note: edited for brevity)

Now the short answer is this question is yes, this window does indeed exist, but to understand the duration of the window (and hence the likelihood of this situation occurring), one has to look a little deeper into how Alfresco WCM deployment works, and more importantly how the FSR attempts to implement ACID transactions on top of non-transactional filesystems.

FSRs basically implement transactional deployment via the following process:

All of the content modifications received from the authoring environment as part of a single deployment job are written to the depdata directory
Assuming step #1 succeeds in its entirety, the transaction is committed, which involves replicating the changes across from the depdata directory to the target directory (this step is assumed to succeed - it’s conceptually the same as the commit phase in the 2 phase commit protocol)
Assuming step #1 fails at some point, the transaction is rolled back, which involves reseting the depdata directory and leaving the target directory untouched

Now in terms of ACIDity, this:

Is Atomic - all changes either appear in the target directory or none of them do
Is (mostly*) Consistent - prior to step 2 the target directory contains the content from the previously deployed snapshot, and after step 2 contains the content from the deployed snapshot, both of which are consistent states for the target directory to be in
Is (mostly*) Isolated - the only process modifying the target directory is the FSR, and read accesses do not require isolation from one another
Is Durable - to the extent that the underlying filesystem is durable

* While the commit phase is in progress, other applications (web servers, app servers, etc.) could read multiple assets that are inconsistent with one another (one is the version prior to deployment while the other is the version post deployment).

So an accurate answer to the original question is yes, there is a window in which an inconsistent state could be read, however that window is limited to the commit phase of the FSR. In database terms, FSR transactions allow both non-repeatable and repeatable (phantom) reads of the target directory while the commit phase is in progress.

But how long is this window, so that we can get a sense for the risk of it occurring?

Well the answer to that is that it depends on both the raw I/O horsepower of the disk subsystem(s) the depdata and target directories are located on, the typical size of the deployment jobs and (to a lesser extent) the makeup of those deployment jobs (file vs directory operations and creates vs updates vs deletes). The good news is that there’s no network I/O during the commit phase (at least not unless either the depdata or target directories are located on a mounted network drive - an architecture that needs to be carefully considered), so the questioner’s concerns about files “not having been copied from the Alfresco WCM authoring environment yet” are unfounded.

This suggests some crude tuning tips for servers that host FSRs:

keep the FSR’s metadata directories on a different disk subsystem to the target directory (it’s typically faster to read from one disk subsystem while writing to another disk subsystem than to do both on the same disk subsystem)
consider using a disk subsystem for the target directory that maximises write performance (eg. RAID 0), but balance this against the (heavy!) read load that’s likely to be coming in from the web server or app server
consider optimising your filesystems and disk subsystem for the typical sizes of assets that you’re deploying (some filesystems perform better or worse with small files, for example)

In addition, in Alfresco v3.0 the commit phase has been optimised via the use of multi-threading and java.nio, which should reduce the duration of the commit window, particularly for large deployment jobs.

The email conversation then moved on to ways that this window might be mitigated, but I’ll reserve that as a topic for my next post.

Posted in Development, wcm | 1 Comment »

Two New Tech Talk Live Recordings Posted

October 3rd, 2008 . by Luis Sala

Two new recordings of Tech Talk Live are now posted.

They’re at the bottom of the Episode Guide:

http://wiki.alfresco.com/wiki/Live#Episode_Guide

Posted in Tech Talk Live | No Comments »

Transparency - benefits and obligations

August 6th, 2008 . by Scott Davis

Whether in accounting, politics, or software - there’s been an increasing amount of lip service paid to transparency. What a great word to fit into a sound bite. It conjures up images of light, and by slight extension, truth. Nobody wants to be in the “dark”, so transparency must be good, right? In general, sure. But why - other than the feel good factor, why should anyone care about transparency?

Having personally observed this force at play in Open Source for the last year now, I see the key benefits of:

Holding people accountable - if all the facts are exposed, there’s little to no wiggle room for any misunderstandings: intentional or not. Pass thru the data and minimize the “spin”. Allow people to make decisions based on real data.
Fostering discussion - as a corollary to the above: examining data allows for questions, interactions, and analysis from several angles. Any results are more keenly understood, with less assumptions.

These are the true benefits, and more importantly obligations of transparency.

Specific to software, it’s what RFPs and POCs have attempted to sift out for years. Nothing facilitates it better than Open Source.

You have access to everything in the company, from the source code on up. Download the product, see it in action, read thru the docs — and — directly compare what it does to your key business requirements.

Posted in Uncategorized | No Comments »

Tech Talk Live Session #7 Recording Available

August 1st, 2008 . by Luis Sala

A recording of Today’s Tech Talk Live session is now available.

Today we discuss Alfresco Share, Alfresco Surf Platform, customized dynamic constraints and answer attendee questions on a variety of topics.

View the recording at:
http://alfresco.na3.acrobat.com/p81993176/

Posted in Uncategorized | No Comments »

Tech Talk Live Starts TODAY at 17:00 BST/ 16:00 UTC / 12:00pm EDT / 9:00am PDT

August 1st, 2008 . by Luis Sala

Alfresco Tech Talk Live is a series of regularly scheduled sessions where attendees get to guide the discussion. Alfresco will host the sessions along with a panel of subject matter experts who will be prepared to answer your questions.

Today’s topics will include:

Introduction to Alfresco 3.0 Labs including Alfresco Share
Introduction to Alfresco’s new Surf Platform
Introduction to the Alfresco Network
Much more!

Learn more at: http://wiki.alfresco.com/wiki/live

Join us at: http://alfresco.acrobat.com/live

Posted in Uncategorized | 1 Comment »

Tomorrow’s Tech Talk Live

July 31st, 2008 . by Luis Sala

The Alfresco engineering team has been working really hard on our new 3.0 release and we’re ready to show you the goods during tomorrows Tech Talk Live.

Topics will include: