Eric -
> I just think that in a service-oriented software package that, by
design,
> will crash in the event of X (taking all other App Servers, WebDAV
and
> XCC connections with it), then X shouldn't necessarily be available
by default.
For clarification:
1) I don't believe that a deadlock will crash the software package.
Your thread will just never complete, and it will keep trying, burning
some CPU resources. That document will pretty much become
inaccessible to other update requests. Aside from that, all ther
threads will, in general, keep running. Yes, to clear out that thread
you will need to restart the server - but you can control the point at
which that happens. So I don't think it's not quite as bad as you
paint it.
2) The reason that it reasonably allows you to do this by default is
probably twofold:
a) The option was added in a release subsequent to the original
xdmp:eval() release, when it became apparent that very occcassionally,
developers were encountering this problem. By making this the "new"
default, the behavior of every existing XQuery program that used eval
would have changed. Instead, a decent decision might be to provide a
mechanism for protecting yourself, and not potentially break existing
developer code.
b) Deadlock aside, as a matter of programming, using eval (and more
importantly, invoke et al) to get to a different context could easily
be the more common case than the same-context case. So it seems like
a reasonable default.
Of course, this doesn't change anything. But perhaps it provides
better colour behind what you see as an unreasonable design.
Cheers
ian
PS. These are just my personal opinions.
On Feb 23, 2009, at 8:59 AM, Eric Palmitesta wrote:
Geert,
Maybe it is a bit harsh, but I think I stand by it. I know what
deadlocks are, and now how to avoid them in MarkLogic Server. I
just think that in a service-oriented software package that, by
design, will crash in the event of X (taking all other App Servers,
WebDAV and XCC connections with it), then X shouldn't necessarily be
available by default. The developer should explicitly (as if
signing a consent form) say "I know what deadlocks are, I understand
the risks, I won't crash the server, promise."
Eric
Geert Josten wrote:
Hi Eric,
You sound quite harsh on your judgement. Note that xdmp:eval is not
a commonly used function, and the isolation option is most likely
used even less. And also note that a deadlock will happen only in
specific situations. I will give an example below..
About update statements, there should be examples mentioned
somewhere. It sais update statements are calls to xdmp:document-
insert and alike. And if an Xquery script contains them somewhere,
the transaction of the Xquery script switches to update mode. In
that case it will request read and write locks on resources that
are being accessed, but only at the moment they are accessed.
If you are in an update-mode transaction, and you update a document
named '/mydoc.xml', then use xdmp:eval with isolation = different-
transaction and the deadlock-prevention to false, while updating
the same document from within the eval, the eval will wait for the
calling transaction to release the update lock, but that will never
happen as the calling transaction is waiting for the eval to finish
first.
Once you understand it, it is not that hard to prevent.. ;-)
Kind regards,
Geert
-----Original Message-----
From: [email protected] [mailto:[email protected]
] On Behalf Of Eric Palmitesta
Sent: vrijdag 20 februari 2009 17:44
To: General Mark Logic Developer Discussion
Subject: Re: [MarkLogic Dev General] dynamic module import
Yep, read the dev guide, and have wondered why <prevent-deadlocks>
is false by default. Sounds like:
"There's a situation in which ML will undetectably deadlock and
you'll have to kill your services while you restart the server.
Oh, but you can completely avoid the deadlock and have a nice
warning printed for you instead by setting this option to 'true',
but we'll allow you to shoot yourself in the foot by default."
Why wouldn't the server-breaking-behavior be constrained to those
who explicitly wished to venture into deadlock territory by
setting <prevent-deadlocks> to 'false' (from a default of 'true')?
(Don't get me wrong, there's likely a good explanation, and it's
likely over my head, but this is what <prevent-deadlocks>
defaulting to false "sounds like")
Also, a question about what an update statement is. A "statement"
is described as "a unit of XQuery code", and an "update statement"
is "a statement which has the potential to perform updates".
declare function do-update() { node-replace(...), 'done' };
let $x = doc('blah')/somenode/text()[1]
let $y = do-update()
return concat($x, $y)
Is that whole thing an update statement? Is that a query
statement, except for the first statement of the do-update()
function, which is an update statement? What exactly constitutes
a "unit" of XQuery code?
Actually, I can test this myself using xdmp:request-timestamp()!
EP
Geert Josten wrote:
Hi Eric,
I am sure there are other ways to achieve what you want,
but if you really would like to do something like that, you could
always resort to xdmp:eval (most likely with <isolation>different-
transaction</isolation> within the options).
Be aware of the transaction mechanism if you start using
eval like that, it can easily put you on a wrong foot if you
haven't at least read the dev guide about it.. ;-)
Kind regards,
Geert
Drs. G.P.H. Josten
Consultant
http://www.daidalos.nl/
Daidalos BV
Source of Innovation
Hoekeindsehof 1-4
2665 JZ Bleiswijk
Tel.: +31 (0) 10 850 1200
Fax: +31 (0) 10 850 1199
http://www.daidalos.nl/
KvK 27164984
De informatie - verzonden in of met dit emailbericht - is
afkomstig van Daidalos BV en is uitsluitend bestemd voor de
geadresseerde. Indien u dit bericht onbedoeld hebt ontvangen,
verzoeken wij u het te verwijderen. Aan dit bericht kunnen geen
rechten worden ontleend.
From: [email protected]
[mailto:[email protected]] On Behalf Of
Eric Palmitesta
Sent: donderdag 19 februari 2009 18:50
To: ML Developer Mailing List
Subject: [MarkLogic Dev General] dynamic module import
I'm fairly sure this isn't possible, but I might as well ask.
Is there any way to import a particular module at runtime?
I know this won't work, but it shows the idea:
import module namespace blah = "http://blah"; at $filename;
It won't work because import statements must come before not
only functions (and code, in the case of a main module), but
before variable declarations as well.
Can someone confirm?
Thanks,
Eric
_______________________________________________
General mailing list
[email protected]
http://xqzone.com/mailman/listinfo/general
_______________________________________________
General mailing list
[email protected]
http://xqzone.com/mailman/listinfo/general
_______________________________________________
General mailing list
[email protected]
http://xqzone.com/mailman/listinfo/general
_______________________________________________
General mailing list
[email protected]
http://xqzone.com/mailman/listinfo/general
_______________________________________________
General mailing list
[email protected]
http://xqzone.com/mailman/listinfo/general
_______________________________________________
General mailing list
[email protected]
http://xqzone.com/mailman/listinfo/general
