Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <dev@myfaces.apache.org>
Received-SPF: pass (nike.apache.org: domain of gcjmu-myfaces-dev@m.gmane.org
 designates 80.91.229.12 as permitted sender)
To: dev@myfaces.apache.org
From: Werner Punz <werner.punz@gmail.com>
Subject: Re: ext-scripting status
Date: Fri, 11 Dec 2009 22:57:56 +0100
Lines: 78
Message-ID: <hfuf93$vue$1@ger.gmane.org>
References: <hfp5ki$ljv$1@ger.gmane.org>
	 <2332f63b0912091404n4632ca7bme89a4d1dbcb27231@mail.gmail.com>
	 <237ac0b0912092347w78be3fe0g3c4b3581f5e57e8c@mail.gmail.com>
	 <hfqs52$i21$2@ger.gmane.org>
	 <237ac0b0912100711o2af230e8w376e56426fc31b46@mail.gmail.com>
	 <71235db40912100719p7fdceeadra2bca97a54597417@mail.gmail.com>
 <237ac0b0912101119u711a0b09k4d10285051e37eb5@mail.gmail.com>
 <hftoe3$hbt$1@ger.gmane.org> <4B227007.5000205@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
In-Reply-To: <4B227007.5000205@gmail.com>
Sender: news <news@ger.gmane.org>

Bernhard Huemer schrieb:
> Hey,
> 
>  > but there is another issue regarding Windows yet, I
>  > also have not set the mutexes in the compiler parts
>  > to avoid windows filelocking if more than one user
>  > hits the server.
> 
> now I'm not entirely sure anymore what you think this module's usage is 
> intended to be like or maybe I'm just getting some implementation 
> details wrong, but I thought that it's a developer changing some bits of 
> a source file who triggers the compilation process (i.e. a daemon thread 
> will pick up those changes and issue compilation, isn't that the case?)? 
> There's no user (user != developer) involved in the whole process at 
> all, is there? Hence the only race condition that I can see is like what 
> happens if two or more developers edit the same source file, and I doubt 
> you want to even bear that race condition in mind.
> 

First: developer == user in my description, the users for me are the 
users of the extension which is the developers!

Now to the details:

The daemon thread just marks the files as tainted and tbe compile then 
happens at the next request before the jsf lifecycle kicks in.
(jsp like)

I�d rather have a single pretictable triggering point than having the 
compiler being triggered continously in unpredictable manner.
A standalone developer can code and save and can cause continous errors.
But at the time he hits refresh, he can be pretty sure that
his code should work (well often it does not but that is a different matter)

> Even if it's the user who triggers the compilation process (i.e. this 
> case assumes you only recompile changed source files on demand), I think 
> you don't have to worry about file locking as long as you synchronize 
> the compiler usage. 

Those are the mutexes I was talking about which are currently missing 
;-), I have not coded them in yet.

A compiler for a single language should only be triggered by one user at 
all even in concurrency mode, hence you have to set a mutex/synchronized 
region per language. Windows really enforces this, two people compiling 
at the same time -> file locks!

In unix well no one cares!

Anyway we probably can ease that limitation between languages so 
parallel java and groovy compile should not be an issue.
But parallel java compilation is a no go!


>Nonetheless I still doubt that it's the user who 
> triggers that, so that's just hypothetical and irrelevant nonsense anyway.
> 
Ouch that did hurt ;-)

No this is not hypothethical nonsense, you just get this usecase
basically if you have to hot patch deployments and several people work 
on it.

Several developers doing it parallely is absolutely the worst case which 
can happen, but as usual if you dont think it will ever happen, it 
definitely will! Give people technology and you will be surprised what 
happens and in ways you never really would think of.

Sure it is rather hypothehical, but why leave it out, if it is just a 
usecase which is easily covered by adding synchronized at the correct parts.

Anyway  I will not recommend to do it, but on the other hand I would 
even make a bet that within the 1.0 - 1.1 timeframe someone will use it 
exactly like that.
And in the end it comes down to having a synchronized being set at the 
correct part of the code, so why not using it.