Hopbot log for 2008-11-03 - Helma IRC channel: #helma on irc.freenode.net

2008-11-03:

[14:16] <lehni> hannes?
[15:50] <lehni> i have a question regarding persistence and write locks in helma. Anyone here who thinks he can answer that?
[16:06] <zumbrunn> nope, not me
[16:34] <lehni> hannes?
[16:35] <lehni> do you have a moment?
[16:40] <hannesw> hi j?rg
[16:41] <hannesw> yep, sure
[16:41] <lehni> i have a question regarding persistence and write locks in helma
[16:42] <lehni> i realised that setting non-persistable properties still wants the write lock. this i guess is a bug
[16:42] <lehni> i already submitted a patch for that, but it made me think...
[16:42] <lehni> let's say there is an action on a hopobject that increases a hit counter, and many people hit that page
[16:43] <lehni> i will get ConcurrencyExceptions that will make the RequestEvaluator restart the request after a while
[16:44] <hannesw> is this for non-persistent objects?
[16:44] <hannesw> http://helma.org/bugs/show_bug.cgi?id=649
[16:44] <lehni> no, persistent objects, e.g. page nodes
[16:44] <hannesw> so it's not bug 649?
[16:44] <lehni> the bug is for non-persistable properties (names starting with '_') on persistent objects
[16:45] <lehni> so in a way it's linked to 649
[16:45] <lehni> 649 is the solution to a problem that made me think about helma's ways of doing these things
[16:47] <hannesw> so you would propose a change that goes beyond the patch in 649?
[16:51] <hannesw> j?rg, are you still there?
[16:53] <lehni> sorry
[16:53] <lehni> back now
[16:53] <hannesw> no problem
[16:53] <lehni> i am just curious
[16:54] <lehni> my problem was that bootstrap was setting _base on hopobjects, which was fetching the write lock
[16:54] <hannesw> so do you think there's a problem beyond locking non-persistent objects and properties?
[16:54] <lehni> and it slowed the page down a lot, as soon as the main html was beeing rendered and an image was fetched from the same node
[16:54] <lehni> i tricked this down to this concurency problem
[16:54] <lehni> the request evaluator retries 8 times
[16:55] <lehni> and waits inbetween with increasing times
[16:55] <lehni> int base = 800 * tries;
[16:55] <lehni> Thread.sleep((long) (base + (Math.random() * base * 2)));
[16:55] <lehni> it made me wonder about two things:
[16:55] <lehni> 1. are write locks really needed?
[16:55] <lehni> 2. should there be a queue for writing evaluators instead of this random waiting time?
[16:56] <lehni> waiting evaluators i mean
[16:56] <lehni> let's imagine a page that's hit a lot and that's increasing a hit counter each time it is hit
[16:56] <hannesw> yes, I think write locks are needed for shared persistent objects
[16:57] <lehni> this would cause a lot of transactors wait and retry randomly
[16:57] <hannesw> implementation is debatable of course
[16:57] <hannesw> yes, that can happen.
[16:57] <lehni> a hit counter is something quite basic...
[16:57] <lehni> one would expect this to be easy to implement
[16:58] <lehni> at the moment, the way to go seems to use app.invokeAsync for the setting of the increased counter
[16:58] <lehni> and let the main action just do the fast serving of the page
[16:58] <lehni> this feels excessive though
[16:58] <lehni> i was curious to hear your thoughts
[16:59] <lehni> also, i was curious to hear about the write lock. it seems to be set once the first transactor starts modifying an object, and cleared only again on commit
[17:00] <hannesw> the good thing about the implementation is that it avoids deadlocks pretty well
[17:00] <lehni> ok
[17:00] <hannesw> if you wait for a lock to be released you get into deadlocks pretty easily
[17:00] <lehni> but do we really need these locks?
[17:00] <lehni> can we not just set the value, and mark the object dirty?
[17:01] <lehni> whatever value it then has when it's commited?
[17:01] <lehni> doesn't really matter it seems
[17:01] <hannesw> that's ok for a simple counter, but not much else i think
[17:01] <lehni> i guess so...
[17:01] <lehni> is it ok for any simple type property?
[17:01] <lehni> e.g. integer, text, varchar, etc
[17:01] <hannesw> bug i agree it should be avoidable in some way
[17:02] <lehni> i was just a bit shocked to see this behavior. although caused by another bug, i could easily imagine scenarios where this becomes an issue
[17:03] <hannesw> yes it's quite suboptimal for counter stuff
[17:03] <hannesw> in antville there's an async db updater that handles page counts
[17:03] <hannesw> but i think it's ok for content etc
[17:03] <lehni> so do you think simple page types do need write locks? i dont think they do
[17:04] <lehni> not page types, property types, sorry
[17:04] <lehni> i wonder how activerecords handles these things...
[17:04] <hannesw> i think so...
[17:04] <hannesw> i'm open to suggestions and alternative implementations
[17:05] <lehni> well, i have no clue
[17:05] <lehni> was curious to hear your thoughts
[17:05] <hannesw> i'll look at your recent bugs this evening
[17:05] <hannesw> gotta go now
[17:05] <lehni> ok
[17:05] <lehni> bye bye!
[17:05] <hannesw> bye!
[17:55] <jirkap> hello, first thanks to Chris who kindly answered my question at the forum. It helped a bit, I read the framework overview again, but
[17:56] <jirkap> I do not understand one thing, which is probably crucial to understand how Helma works:
[17:58] <jirkap> let's say I have some main_action() defined in Root, for my own organisation I want another folder in my appdir called Sample, in which I could define another main_action()
[17:59] <jirkap> so this action could be accessible at http://somewhere/sample/, but it does not work. WHY?
[18:00] <jirkap> I mean, I do not need/want to have such an organisation, but what is the catch here?
[18:02] <jirkap> also - the inspector says that the Root HopObject has no child objects, I have no idea how to wire Sample to Root.
[18:25] <zumbrunn> hi jirkap
[18:25] <zumbrunn> I'm just running by the keyboard right now and don't have time to read and respond
[18:25] <zumbrunn> will do so in a bit though
[18:25] <zumbrunn> brb
[18:36] <jirkap> sure. I will have to leave in few minutes though, but I am going to see the channel log tommorrow, so your answer will definitely not be missed, thanks.
[19:02] <zumbrunn> the url request path are mapped to "objects", not the folders in your app dir
[19:03] <zumbrunn> "objects" are instances of a prototype
[19:04] <zumbrunn> and the folders in your app dir are where you define those prototypes
[19:05] <zumbrunn> so, in order to make http://somewhere/sample/ work, you need to create a new object of some prototype and add it to the root object as a child
[19:07] <zumbrunn> for example, look at the way the HopObjects behave inside the welcome app
[19:07] <zumbrunn> http://helma.zumbrunn.com/first/second/
[19:09] <zumbrunn> type.properties defines an accessname: https://dev.helma.org/trac/helma/browser/apps/welcome/trunk/code/HopObject/type.properties
[19:11] <zumbrunn> and there is an "add" action that creates a new child object with a name property and attaches it to the parent object:
[19:11] <zumbrunn> https://dev.helma.org/trac/helma/browser/apps/welcome/trunk/code/HopObject/add.hac
[19:15] <zumbrunn> so, you would create a new HopObject with a name property "sample" and attach it to the root object
[19:16] <zumbrunn> var foo = new HopObject(); foo.name = "sample"; root.add(foo);
[19:18] <zumbrunn> or, if you create a Sample folder in your appdir, you can then create new objects of the type "Sample" you specified
[19:20] <zumbrunn> var mySampleObj = new Sample(); mySampleObj.name = 'foo'; root.add(mySampleObj);
[19:20] <zumbrunn> then you could access that Sample object at http://somewhere/foo/
[19:21] <zumbrunn> and it would be the main action inside your Sample directory that gets called, not the one in the Root dir
[19:35] <zumbrunn> hannesw: for what it's worth... I'm ready for rc2 anytime you are
[19:37] <hannesw> ok
[19:38] <zumbrunn> btw, decke suggested that we include the rc release number in the file names of tour release candidates
[19:39] <zumbrunn> (not just in the directory name)
[19:39] <hannesw> what file names?
[19:39] <hannesw> package names?
[19:39] <zumbrunn> yes
[19:39] <hannesw> yes, I'm to lazy for that really :-)
[19:39] <zumbrunn> :-)
[19:40] <hannesw> it's just a matter of changing the version in build.xml
[19:40] <zumbrunn> or even just renaming the filenames of the generated packages
[19:41] <zumbrunn> (not the same, but better than nothing)
[19:43] <zumbrunn> (plus, you can then still reuse the same packages if they become final)
[19:44] <hannesw> do you feel like doing that, chris?
[19:44] <hannesw> if you want I can send you the root pw for adele
[19:44] <zumbrunn> ok, I would do it tomorrow morning, though
[19:45] <hannesw> ok.

 

 

In the channel now:

Logs by date: