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 you compile continuously the developer can introduce mistakes,
save them and the application won't pick them up as it simply doesn't
compile anyway - or do you mean runtime errors? Just thinking about it -
apparently it doesn't really matter at which point you pick up the
changes as long as you pick them up at all (which you do), which
basically means, if the developer introduces runtime errors at runtime
it will affect your application regardless of whether you recompile it
JSP-like or not (btw. using the term "JSP-like" as a way to express how
you manage compilation isn't really precise either as e.g. the Jasper 2
engine provides background compilation as well - but let's stick with
the usual approach to define what "JSP-like" means).
Anyhow if it works JSP-like in your case, then you can't just treat
users and developers the same. The relationship that any developer who
uses your module is a user of your module doesn't really matter when it
comes to race conditions, so I'd suggest we'll ignore that fact.
However, what matters is that there are people who issue requests to the
web server, namely the users, and people who actually modify the source
files of those applications, the developers. The problem with the users
requests being the "compilation trigger" is apparently that you'll
have to deal with race conditions as there are multiple possible request
threads. If, however, the developer, or more precisely said the daemon
thread that checks for file modifications, triggers compilations you've
only got one thread - the file monitoring thread - that could possibly
access the compiler, hence no need for synchronization at all in this case!
Well, we've already talked about it a lot anyway, and it's probably just
a matter of preference, I just wanted to point out some issues and
compare different approaches. Maybe others want to follow that
discussion as well, which is why I'm still responding to this emails as
well.
regards,
Bernhard
Werner Punz wrote on 12/11/2009 09:57 PM (GMT):
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.
