Menu
▾
▴
exist-development — eXist Developer's List
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(22) |
Nov
(85) |
Dec
(20) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2010 |
Jan
(47) |
Feb
(127) |
Mar
(268) |
Apr
(78) |
May
(47) |
Jun
(38) |
Jul
(131) |
Aug
(221) |
Sep
(187) |
Oct
(54) |
Nov
(111) |
Dec
(84) |
| 2011 |
Jan
(152) |
Feb
(106) |
Mar
(94) |
Apr
(90) |
May
(53) |
Jun
(20) |
Jul
(24) |
Aug
(37) |
Sep
(32) |
Oct
(70) |
Nov
(22) |
Dec
(15) |
| 2012 |
Jan
(33) |
Feb
(110) |
Mar
(24) |
Apr
(1) |
May
(11) |
Jun
(8) |
Jul
(12) |
Aug
(37) |
Sep
(39) |
Oct
(81) |
Nov
(38) |
Dec
(50) |
| 2013 |
Jan
(23) |
Feb
(53) |
Mar
(23) |
Apr
(5) |
May
(19) |
Jun
(16) |
Jul
(16) |
Aug
(9) |
Sep
(21) |
Oct
(1) |
Nov
(2) |
Dec
(8) |
| 2014 |
Jan
(16) |
Feb
(6) |
Mar
(27) |
Apr
(1) |
May
(10) |
Jun
(1) |
Jul
(4) |
Aug
(10) |
Sep
(19) |
Oct
(22) |
Nov
(4) |
Dec
(6) |
| 2015 |
Jan
(3) |
Feb
(6) |
Mar
(9) |
Apr
|
May
(11) |
Jun
(23) |
Jul
(14) |
Aug
(10) |
Sep
(10) |
Oct
(9) |
Nov
(18) |
Dec
(4) |
| 2016 |
Jan
(5) |
Feb
(5) |
Mar
|
Apr
(2) |
May
(15) |
Jun
(2) |
Jul
(8) |
Aug
(2) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
(2) |
Feb
(12) |
Mar
(22) |
Apr
(6) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(5) |
Oct
(2) |
Nov
|
Dec
|
| 2018 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(5) |
Jul
(3) |
Aug
|
Sep
(7) |
Oct
(19) |
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Dmitriy S. <sha...@gm...> - 2011-09-07 11:00:06
|
So, only 1.5 have this issue? On Wed, Sep 7, 2011 at 3:05 PM, Dannes Wessels <da...@ex...> wrote: > situation in 1.4 seems to be better... the thread 'dies' in 30 secs. With > an error, but that is ok... > > > On Wed, Sep 7, 2011 at 12:03 PM, Dannes Wessels <da...@ex...>wrote: > >> To clarify things... the situation described has nothing to do with a >> reverse proxy or what so ever. It is more like the server is running in a >> DMZ, meaning the software in that zone cannot access other servers (on the >> internet). Hostnames are resolved since DNS is fully functional. >> >> > > -- > eXist-db Native XML Database - http://exist-db.org > Join us on linked-in: http://www.linkedin.com/groups?gid=35624 > > > ------------------------------------------------------------------------------ > Using storage to extend the benefits of virtualization and iSCSI > Virtualization increases hardware utilization and delivers a new level of > agility. Learn what those decisions are and how to modernize your storage > and backup environments for virtualization. > http://www.accelacomm.com/jaw/sfnl/114/51434361/ > _______________________________________________ > Exist-development mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-development > > -- Dmitriy Shabanov |
|
From: Dannes W. <da...@ex...> - 2011-09-07 10:05:51
|
situation in 1.4 seems to be better... the thread 'dies' in 30 secs. With an error, but that is ok... On Wed, Sep 7, 2011 at 12:03 PM, Dannes Wessels <da...@ex...> wrote: > To clarify things... the situation described has nothing to do with a > reverse proxy or what so ever. It is more like the server is running in a > DMZ, meaning the software in that zone cannot access other servers (on the > internet). Hostnames are resolved since DNS is fully functional. > > -- eXist-db Native XML Database - http://exist-db.org Join us on linked-in: http://www.linkedin.com/groups?gid=35624 |
|
From: Dannes W. <da...@ex...> - 2011-09-07 10:04:08
|
To clarify things... the situation described has nothing to do with a reverse proxy or what so ever. It is more like the server is running in a DMZ, meaning the software in that zone cannot access other servers (on the internet). Hostnames are resolved since DNS is fully functional. D. On Wed, Sep 7, 2011 at 9:14 AM, Dannes Wessels <da...@ex...> wrote: > Hi, > > I found out that when existdb runs isolated, behind a corporate firewall, > one or two threads keep hanging on an HTTP connection; when try to shut down > the db I see the following trace (exist.log): > > 2011-09-07 09:06:16,244 [jetty shutdown schedule] INFO (JettyStart.java > [lifeCycleStopped]:406) - Jetty server stopped > 2011-09-07 09:06:28,613 [eXistThread-994] WARN (URLSource.java > [getInputStream]:140) - Unable to connect to URL: Connection timed out > 2011-09-07 09:06:28,614 [eXistThread-994] ERROR (FunDoc.java [eval]:122) - > Connection timed out ( > http://atomic.exist-db.org/atom/summary/wiki/blogs/eXist/) > 2011-09-07 09:06:28,615 [eXistThread-994] ERROR (XQueryServlet.java > [process]:573) - > java.lang.NullPointerException > at > org.exist.http.servlets.XQueryServlet.process(XQueryServlet.java:515) > at > org.exist.http.servlets.XQueryServlet.doGet(XQueryServlet.java:217) > .... > > > in std out: > > 07 Sep 2011 09:06:16,244 [jetty shutdown schedule] INFO (JettyStart.java > [lifeCycleStopped]:406) - Jetty server stopped > 07 Sep 2011 09:06:28,619 [eXistThread-994] WARN (Slf4jLog.java [warn]:50) > - /exist/feed.xql > java.lang.NullPointerException > at org.exist.storage.BrokerPool.release(BrokerPool.java:1477) > at > org.exist.http.servlets.XQueryServlet.process(XQueryServlet.java:582) > ... > > while in the html admin interface I see > > IDTypeSourceStartedStatus 2340291File > /usr/local/asm/opt/eXist-1.5/webapp/feed.xql2011-09-07T09:02:43.987+02:00 > terminating > > Probably we need to set an HTTP timeout or so....? any idea? > > cheers > > Dannes > > -- > eXist-db Native XML Database - http://exist-db.org > Join us on linked-in: http://www.linkedin.com/groups?gid=35624 > -- eXist-db Native XML Database - http://exist-db.org Join us on linked-in: http://www.linkedin.com/groups?gid=35624 |
|
From: Adam R. <ad...@ex...> - 2011-09-07 10:03:52
|
I fixed a design issue on the 2nd September as revision 15291 which meant that admin and guest accounts could now be modified again and removed if desired. Unfortunately there was as small bug in the fix whereby the wrong id's were allocated to the admin and guest users. I fixed that bug last night as revision 15310. If you have a database in use between those versions then you should : 1) make a full backup of the database. 2) shutdown your server and 'svn up' to > 15310, rebuild. 3) In the full backup, modify the admin.xml and guest.xml files in /db/system/security/exist/accounts so that their id's are 1048574 and 1048573 respectively. 4) restore the backup. Sorry about the issue... but hopefully its a small problem due to the minimal time window... On 7 September 2011 07:49, Dannes Wessels <da...@ex...> wrote: > All, > > this morning I updated trunk to latest revision, rebuilt and started the > database ; the updated database did not start however.... > > so a warning here for updating trunk ; we are investigating the issue.... > > D. > > -- > eXist-db Native XML Database - http://exist-db.org > Join us on linked-in: http://www.linkedin.com/groups?gid=35624 > > ------------------------------------------------------------------------------ > Using storage to extend the benefits of virtualization and iSCSI > Virtualization increases hardware utilization and delivers a new level of > agility. Learn what those decisions are and how to modernize your storage > and backup environments for virtualization. > http://www.accelacomm.com/jaw/sfnl/114/51434361/ > _______________________________________________ > Exist-development mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-development > > -- Adam Retter eXist Developer { United Kingdom } ad...@ex... irc://irc.freenode.net/existdb |
|
From: Dannes W. <da...@ex...> - 2011-09-07 07:50:10
|
All, this morning I updated trunk to latest revision, rebuilt and started the database ; the updated database did not start however.... so a warning here for updating trunk ; we are investigating the issue.... D. -- eXist-db Native XML Database - http://exist-db.org Join us on linked-in: http://www.linkedin.com/groups?gid=35624 |
|
From: Dannes W. <da...@ex...> - 2011-09-07 07:15:08
|
Hi, I found out that when existdb runs isolated, behind a corporate firewall, one or two threads keep hanging on an HTTP connection; when try to shut down the db I see the following trace (exist.log): 2011-09-07 09:06:16,244 [jetty shutdown schedule] INFO (JettyStart.java [lifeCycleStopped]:406) - Jetty server stopped 2011-09-07 09:06:28,613 [eXistThread-994] WARN (URLSource.java [getInputStream]:140) - Unable to connect to URL: Connection timed out 2011-09-07 09:06:28,614 [eXistThread-994] ERROR (FunDoc.java [eval]:122) - Connection timed out ( http://atomic.exist-db.org/atom/summary/wiki/blogs/eXist/) 2011-09-07 09:06:28,615 [eXistThread-994] ERROR (XQueryServlet.java [process]:573) - java.lang.NullPointerException at org.exist.http.servlets.XQueryServlet.process(XQueryServlet.java:515) at org.exist.http.servlets.XQueryServlet.doGet(XQueryServlet.java:217) .... in std out: 07 Sep 2011 09:06:16,244 [jetty shutdown schedule] INFO (JettyStart.java [lifeCycleStopped]:406) - Jetty server stopped 07 Sep 2011 09:06:28,619 [eXistThread-994] WARN (Slf4jLog.java [warn]:50) - /exist/feed.xql java.lang.NullPointerException at org.exist.storage.BrokerPool.release(BrokerPool.java:1477) at org.exist.http.servlets.XQueryServlet.process(XQueryServlet.java:582) ... while in the html admin interface I see IDTypeSourceStartedStatus 2340291File /usr/local/asm/opt/eXist-1.5/webapp/feed.xql2011-09-07T09:02:43.987+02:00 terminating Probably we need to set an HTTP timeout or so....? any idea? cheers Dannes -- eXist-db Native XML Database - http://exist-db.org Join us on linked-in: http://www.linkedin.com/groups?gid=35624 |
|
From: Dannes W. <da...@ex...> - 2011-09-02 20:48:15
|
All, On 7 Aug 2011, at 19:42 , Joe Wicentowski wrote: > On Sat, Aug 6, 2011 at 5:12 AM, Dannes Wessels <da...@ex...> wrote: > > sure, let's do it. I'd like to propose a to step thing…. > > (1) just upgrade to 0.9 in trunk I updated the build of the content extraction module a bit; when the extension is enabled it downloads the parser jar plus all dependancies using ivy ; public maven repositories are used. redundant jars are NOT downloaded. at least this should reduce the slf4j warnings when starting exist-db….. cheers Danns |
|
From: Ron V. d. B. <ron...@ka...> - 2011-09-01 13:23:43
|
Hi, Ralf Jung wrote: > as discussed in the "[Exist-open] Forbidden re-ordering of a sequence" > thread, I wrote a summary of the issues in the eXist XQuery evaluation > that I am aware of. Excellent idea! I'd volunteer in helping to contribute to this. Adam Retter wrote: > Probably would be good to add an official page to eXist-db's source > code, linked form the XQuery documentation called something like > 'eXist-db XQuery quirks and known issues' From my experience, I realize it's not always easy to pin down such bugs and formulate quality test expressions. Moreover, some of them might be related, and higher-order patterns might appear only afterwards. Hence, I'm convinced that collecting such quirks can be a messy business, which definitely benefits from collaboration. Therefore, I'd like to ask what would be the preferred way forward, from the developers' point of view? Just committing this page to the webapps folder (I can do this) and edit it along the way, or would you prefer a prior 'stabilizing' phase, where ideas / refinements are collected somewhere outside the eXist source tree (though that's perhaps what the bug tracker is for?)? In the latter case, would <http://en.wikibooks.org/wiki/XQuery/> be a good place? Kind regards, Ron -- Ron Van den Branden Wetenschappelijk attaché / Senior Researcher Reviews Editor LLC. The Journal of Digital Scholarship in the Humanities Centrum voor Teksteditie en Bronnenstudie - CTB (KANTL) Centre for Scholarly Editing and Document Studies Koninklijke Academie voor Nederlandse Taal- en Letterkunde Royal Academy of Dutch Language and Literature Koningstraat 18 / b-9000 Gent / Belgium tel: +32 9 265 93 51 / fax: +32 9 265 93 49 E-mail : ron...@ka... http://www.kantl.be/ctb |
|
From: Patrick B. <pat...@jo...> - 2011-08-10 20:45:11
|
On Wed, Aug 10, 2011 at 8:46 AM, Adam Retter <ad...@ex...> wrote:
> >> So what did you make of my proposals (August 8th) for changes to the
> >> code, and can you comment on why we release the internal READ lock but
> >> tell WebDAV that its locked - that seems dangerous to me, but there
> >> are probably some webdav specific reasons?
> >
> > The internal locks should *never* be held across invocations. They
> > have to be released before a transaction commits or you'll block other
> > threads.
>
> If the lock is released before the transaction is committed is it not
> possible the thread could be preempted and the resource modified by
> another thread and committed before this one is committed?
>
> > The WebDAV (or user level) locks are for applications to implement
> > their own locking scheme. It is up to the application or interface to
> > enforce those.
>
> But what happens if WebDAV or another applications, thinks that it has
> locked something in eXist-db, but it has not and another API removes
> this resources. Surely locking has to be end to end?
>
I want to throw in my two cents as a application developer that uses the
token locking system extensively. It's true that the token locking system
isn't a fail safe method, and there is the potential that an unintended move
or delete could impact someone working through webDAV or some other
connection. However, in my opinion, this isn't (and shouldn't be) eXist's
responsibility. This falls into the hands of the app developer. I feel it's
eXist's responsibility to provide the app developer good tools to mitigate
this situation (which it does) and then to stay out of the way as much as
possible.
> > Wolfgang
> >
>
>
>
> --
> Adam Retter
>
> eXist Developer
> { United Kingdom }
> ad...@ex...
> irc://irc.freenode.net/existdb
>
>
> ------------------------------------------------------------------------------
> uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing Subversion and
> the tools developers use with it. Learn more about uberSVN and get a free
> download at: http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Exist-development mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-development
>
--
Patrick Bosek
Jorsek Software
Cell (585) 820 9634
Office (877) 492 2960
Jorsek.com
|
|
From: Adam R. <ad...@ex...> - 2011-08-10 12:46:21
|
>> So what did you make of my proposals (August 8th) for changes to the
>> code, and can you comment on why we release the internal READ lock but
>> tell WebDAV that its locked - that seems dangerous to me, but there
>> are probably some webdav specific reasons?
>
> The internal locks should *never* be held across invocations. They
> have to be released before a transaction commits or you'll block other
> threads.
If the lock is released before the transaction is committed is it not
possible the thread could be preempted and the resource modified by
another thread and committed before this one is committed?
> The WebDAV (or user level) locks are for applications to implement
> their own locking scheme. It is up to the application or interface to
> enforce those.
But what happens if WebDAV or another applications, thinks that it has
locked something in eXist-db, but it has not and another API removes
this resources. Surely locking has to be end to end?
> Wolfgang
>
--
Adam Retter
eXist Developer
{ United Kingdom }
ad...@ex...
irc://irc.freenode.net/existdb
|
|
From: Wolfgang M. <wol...@ex...> - 2011-08-10 11:00:54
|
> So what did you make of my proposals (August 8th) for changes to the > code, and can you comment on why we release the internal READ lock but > tell WebDAV that its locked - that seems dangerous to me, but there > are probably some webdav specific reasons? The internal locks should *never* be held across invocations. They have to be released before a transaction commits or you'll block other threads. The WebDAV (or user level) locks are for applications to implement their own locking scheme. It is up to the application or interface to enforce those. Wolfgang |
|
From: Adam R. <ad...@ex...> - 2011-08-10 10:24:26
|
Dannes,
So what did you make of my proposals (August 8th) for changes to the
code, and can you comment on why we release the internal READ lock but
tell WebDAV that its locked - that seems dangerous to me, but there
are probably some webdav specific reasons?
On 10 August 2011 11:56, Dannes Wessels <da...@ex...> wrote:
> Hi,
>
> On Wed, Aug 10, 2011 at 11:08 AM, Adam Retter <ad...@ex...> wrote:
>>
>> > I think this is actually working correctly. The function puts a user
>> > lock
>> > and a lockToken on the resource, which (from my understanding) is the
>> > correct way to put a persistent (user level) lock on a document.
>>
>> I think that lockToken is only used for WebDAV and nothing else unless
>> I am mistaken?
>
> yes it is right. it is a 'symbolic' representation of a lock, but it does
> not actually perform any locking....
>
>>
>> > What it's
>> > releasing is the database READ_LOCK, which can block other processes
>> > that
>> > try to read the resource.
>>
>> READ_LOCK does not block other reads, it only blocks other writes.
>
> jups....
>
> D.
>>
>> --
>> Adam Retter
>>
>> eXist Developer
>> { United Kingdom }
>> ad...@ex...
>> irc://irc.freenode.net/existdb
>>
>>
>> ------------------------------------------------------------------------------
>> uberSVN's rich system and user administration capabilities and model
>> configuration take the hassle out of deploying and managing Subversion and
>> the tools developers use with it. Learn more about uberSVN and get a free
>> download at: http://p.sf.net/sfu/wandisco-dev2dev
>> _______________________________________________
>> Exist-development mailing list
>> Exi...@li...
>> https://lists.sourceforge.net/lists/listinfo/exist-development
>
>
>
> --
> eXist-db Native XML Database - http://exist-db.org
> Join us on linked-in: http://www.linkedin.com/groups?gid=35624
>
--
Adam Retter
eXist Developer
{ United Kingdom }
ad...@ex...
irc://irc.freenode.net/existdb
|
|
From: Dannes W. <da...@ex...> - 2011-08-10 09:56:51
|
Hi,
On Wed, Aug 10, 2011 at 11:08 AM, Adam Retter <ad...@ex...> wrote:
> > I think this is actually working correctly. The function puts a user lock
> > and a lockToken on the resource, which (from my understanding) is the
> > correct way to put a persistent (user level) lock on a document.
>
> I think that lockToken is only used for WebDAV and nothing else unless
> I am mistaken?
>
yes it is right. it is a 'symbolic' representation of a lock, but it does
not actually perform any locking....
>
> > What it's
> > releasing is the database READ_LOCK, which can block other processes that
> > try to read the resource.
>
> READ_LOCK does not block other reads, it only blocks other writes.
>
jups....
D.
> --
> Adam Retter
>
> eXist Developer
> { United Kingdom }
> ad...@ex...
> irc://irc.freenode.net/existdb
>
>
> ------------------------------------------------------------------------------
> uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing Subversion and
> the tools developers use with it. Learn more about uberSVN and get a free
> download at: http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Exist-development mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-development
>
--
eXist-db Native XML Database - http://exist-db.org
Join us on linked-in: http://www.linkedin.com/groups?gid=35624
|
|
From: Adam R. <ad...@ex...> - 2011-08-10 09:08:15
|
>> I have just studied the code, and if I understand it correctly then
>> there are a couple of things that seem incorrect here. It early and I
>> cant sleep.
>>
>> Dannes is the master of all things WebDAV, so he may be able to show
>> us what we are misunderstanding.
>>
>> Your comment about the read-lock -- it seems to me that the finally
>> resource lock release, only happens if isNullResource is set, yet when
>> isNullResource is set, the resource is never read locked anyway as far
>> as I can tell.
>>
>> IMHO, this function could be improved by being split into two, its too
>> long and it takes two different actions, in the least it could call
>> out to a function to handle the null resource path. This would make
>> the code easier to understand and test.
>>
>> In its current state I think line 277 should be deleted, and also line
>> 294, and this should fix the locking issue.
>
> This was my first thought as well (and may very well be the correct one).
> But I thought there might be a reason the resource is being unlocked before
> the transct.commit(). But, I haven't spent any time in the transaction
> system, so I really have no idea.
>
>
>>
>> But in addition it seems to me, that this function reports to WebDAV
>> that resources have been locked, but this is not the case as it always
>> unlocks the resource. I am not sure why this would be, but I would of
>> imagined that the resource should remain locked until WebDAV unlocks
>> it?
>>
>
> I think this is actually working correctly. The function puts a user lock
> and a lockToken on the resource, which (from my understanding) is the
> correct way to put a persistent (user level) lock on a document.
I think that lockToken is only used for WebDAV and nothing else unless
I am mistaken?
> What it's
> releasing is the database READ_LOCK, which can block other processes that
> try to read the resource.
READ_LOCK does not block other reads, it only blocks other writes.
>>
>> On 8 August 2011 03:22, Patrick Bosek <pat...@jo...> wrote:
>> > Hi Everyone,
>> >
>> > After many hours of investigation I've found a locking situation in the
>> > WebDAV module which causes database deadlocks. The problem (as I see it)
>> > is
>> > that the webdav.methods.Lock.process() sets a READ_LOCK and has several
>> > cases where it exits without releasing it:
>> >
>> >
>> > -- webdav.methods.Lock.process() -- line 201:
>> >
>> > resource = broker.getXMLResource(path,
>> > org.exist.storage.lock.Lock.READ_LOCK);
>> >
>> > ....
>> >
>> > -- webdav.methods.Lock.process() -- line 249: !!!!! As you can see in
>> > the
>> > case where the resource is already locked, it exists without releasing
>> > it's
>> > READ_LOCK
>> >
>> > // Check if Resource is already locked.
>> > if( lock!=null && !lock.getName().equals(user.getName())
>> > ){
>> > LOG.debug("Resource is locked.");
>> > response.sendError(SC_RESOURCE_IS_LOCKED,
>> > "Resource is locked by user "+
>> > user.getName()
>> > +".");
>> > return;
>> > }
>> >
>> > // Check for request fo shared lock.
>> > if(lockToken.getScope() == LockToken.LOCK_SCOPE_SHARED)
>> > {
>> > LOG.debug("Shared locks are not implemented.");
>> >
>> > response.sendError(HttpServletResponse.SC_NOT_IMPLEMENTED,
>> > "Shared locks are not implemented.");
>> > return;
>> > }
>> >
>> > // Fill new Locktoken with new UUID
>> > lockToken.createOpaqueLockToken();
>> > resource.getMetadata().setLockToken(lockToken);
>> > resource.setUserLock(user);
>> >
>> > // Make token persistant
>> > TransactionManager transact =
>> > pool.getTransactionManager();
>> > Txn transaction = transact.beginTransaction();
>> > broker.storeXMLResource(transaction, resource);
>> > //TOUNDERSTAND : this lock is released below (in the
>> > finally
>> > clause)
>> > //isn't it rather a user lock release attempt ?
>> > // ?
>> >
>> > resource.getUpdateLock().release(org.exist.storage.lock.Lock.READ_LOCK);
>> > !!!!! Here is where it is released when no one else has it locked
>> > transact.commit(transaction);
>> >
>> >
>> >
>> > So, this is an issue which occurs in multi-user systems when two users
>> > try
>> > to access the same document.
>> >
>> > My proposed fix is to simply add releases to the two return cases. I
>> > don't
>> > really understand why the resource isn't just being unlocked in the
>> > finally
>> > in all cases, but I'm guessing there is a reason to release it before
>> > committing the transaction that I don't understand.
>> >
>> > My Fix:
>> >
>> > if( lock!=null && !lock.getName().equals(user.getName())
>> > ){
>> > LOG.debug("Resource is locked.");
>> > response.sendError(SC_RESOURCE_IS_LOCKED,
>> > "Resource is locked by user "+
>> > user.getName()
>> > +".");
>> >
>> >
>> > resource.getUpdateLock().release(org.exist.storage.lock.Lock.READ_LOCK);
>> > return;
>> > }
>> >
>> > // Check for request fo shared lock.
>> > if(lockToken.getScope() == LockToken.LOCK_SCOPE_SHARED)
>> > {
>> > LOG.debug("Shared locks are not implemented.");
>> >
>> > response.sendError(HttpServletResponse.SC_NOT_IMPLEMENTED,
>> > "Shared locks are not implemented.");
>> >
>> >
>> > resource.getUpdateLock().release(org.exist.storage.lock.Lock.READ_LOCK);
>> > return;
>> > }
>> >
>> >
>> > I can provide a patch or simply commit this into the 1.4.x branch if
>> > requested to do so by one of the core developers. But I wanted to ask
>> > first,
>> > since there are things going on here that are above my head.
>> >
>> > Thoughts?
>> >
>> >
>> > Cheers,
>> >
>> > --
>> > Patrick Bosek
>> > Jorsek Software
>> > Cell (585) 820 9634
>> > Office (877) 492 2960
>> > Jorsek.com
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
>> > The must-attend event for mobile developers. Connect with experts.
>> > Get tools for creating Super Apps. See the latest technologies.
>> > Sessions, hands-on labs, demos & much more. Register early & save!
>> > http://p.sf.net/sfu/rim-blackberry-1
>> > _______________________________________________
>> > Exist-development mailing list
>> > Exi...@li...
>> > https://lists.sourceforge.net/lists/listinfo/exist-development
>> >
>> >
>>
>>
>>
>> --
>> Adam Retter
>>
>> eXist Developer
>> { United Kingdom }
>> ad...@ex...
>> irc://irc.freenode.net/existdb
>
>
>
> --
> Patrick Bosek
> Jorsek Software
> Cell (585) 820 9634
> Office (877) 492 2960
> Jorsek.com
>
>
--
Adam Retter
eXist Developer
{ United Kingdom }
ad...@ex...
irc://irc.freenode.net/existdb
|
|
From: Evgeny G. <gaz...@gm...> - 2011-08-10 06:29:19
|
On 10.08.2011 06:35, Loren Cahlander wrote: > Hello Evgeny, > > Thank you for this. I will try it. > > Loren > > On Aug 9, 2011, at 5:44 PM, Evgeny Gazdovsky wrote: > >> On 09.08.2011 23:14, Loren Cahlander wrote: >>> Has anyone integrated Apache POI into eXist to read and write excel spreadsheets? >>> ------------------------------------------------------------------------------ >>> uberSVN's rich system and user administration capabilities and model >>> configuration take the hassle out of deploying and managing Subversion and >>> the tools developers use with it. Learn more about uberSVN and get a free >>> download at: http://p.sf.net/sfu/wandisco-dev2dev >>> _______________________________________________ >>> Exist-development mailing list >>> Exi...@li... >>> https://lists.sourceforge.net/lists/listinfo/exist-development >> Yes I have. >> See example in attachment >> >> Sorry, I'd forgot the small java class. See attachment. There is a listener, that convert POI events into a sequence of the POI records. You will need to compile class and make a jar or use attached hsf-common-listener.jar. Then put one into $EXIST_HOME/lib/user with POI jars. I use next jars: poi-scratchpad-*.jar, poi-ooxml-*.jar, poi-contrib-*.jar, poi. * is POI version -- Evgeny |
|
From: Loren C. <lor...@gm...> - 2011-08-10 02:35:51
|
Hello Evgeny, Thank you for this. I will try it. Loren On Aug 9, 2011, at 5:44 PM, Evgeny Gazdovsky wrote: > On 09.08.2011 23:14, Loren Cahlander wrote: >> Has anyone integrated Apache POI into eXist to read and write excel spreadsheets? >> ------------------------------------------------------------------------------ >> uberSVN's rich system and user administration capabilities and model >> configuration take the hassle out of deploying and managing Subversion and >> the tools developers use with it. Learn more about uberSVN and get a free >> download at: http://p.sf.net/sfu/wandisco-dev2dev >> _______________________________________________ >> Exist-development mailing list >> Exi...@li... >> https://lists.sourceforge.net/lists/listinfo/exist-development > Yes I have. > See example in attachment > > -- > Evgeny > <xls2table.xqm>------------------------------------------------------------------------------ > uberSVN's rich system and user administration capabilities and model > configuration take the hassle out of deploying and managing Subversion and > the tools developers use with it. Learn more about uberSVN and get a free > download at: http://p.sf.net/sfu/wandisco-dev2dev > _______________________________________________ > Exist-development mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-development |
|
From: Evgeny G. <gaz...@gm...> - 2011-08-09 22:45:07
|
On 09.08.2011 23:14, Loren Cahlander wrote: > Has anyone integrated Apache POI into eXist to read and write excel spreadsheets? > ------------------------------------------------------------------------------ > uberSVN's rich system and user administration capabilities and model > configuration take the hassle out of deploying and managing Subversion and > the tools developers use with it. Learn more about uberSVN and get a free > download at: http://p.sf.net/sfu/wandisco-dev2dev > _______________________________________________ > Exist-development mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-development Yes I have. See example in attachment -- Evgeny |
|
From: Loren C. <lor...@gm...> - 2011-08-09 22:04:17
|
I am looking at reading and creating excel files. Sent from my iPhone On Aug 9, 2011, at 4:57 PM, Adam Retter <ad...@ex...> wrote: > No, but I have some experience using POI and my question would be - > how the hell would you wrap their complex programmatic API inside > anything else that would be usable? Thats why I always avoided adding > it to eXist-db so far ;-) > > On 9 August 2011 20:14, Loren Cahlander <lor...@gm...> wrote: >> Has anyone integrated Apache POI into eXist to read and write excel spreadsheets? >> ------------------------------------------------------------------------------ >> uberSVN's rich system and user administration capabilities and model >> configuration take the hassle out of deploying and managing Subversion and >> the tools developers use with it. Learn more about uberSVN and get a free >> download at: http://p.sf.net/sfu/wandisco-dev2dev >> _______________________________________________ >> Exist-development mailing list >> Exi...@li... >> https://lists.sourceforge.net/lists/listinfo/exist-development >> > > > > -- > Adam Retter > > eXist Developer > { United Kingdom } > ad...@ex... > irc://irc.freenode.net/existdb |
|
From: Adam R. <ad...@ex...> - 2011-08-09 21:57:53
|
No, but I have some experience using POI and my question would be - how the hell would you wrap their complex programmatic API inside anything else that would be usable? Thats why I always avoided adding it to eXist-db so far ;-) On 9 August 2011 20:14, Loren Cahlander <lor...@gm...> wrote: > Has anyone integrated Apache POI into eXist to read and write excel spreadsheets? > ------------------------------------------------------------------------------ > uberSVN's rich system and user administration capabilities and model > configuration take the hassle out of deploying and managing Subversion and > the tools developers use with it. Learn more about uberSVN and get a free > download at: http://p.sf.net/sfu/wandisco-dev2dev > _______________________________________________ > Exist-development mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-development > -- Adam Retter eXist Developer { United Kingdom } ad...@ex... irc://irc.freenode.net/existdb |
|
From: Loren C. <lor...@gm...> - 2011-08-09 19:21:53
|
Has anyone integrated Apache POI into eXist to read and write excel spreadsheets? |
|
From: Patrick B. <pat...@jo...> - 2011-08-08 15:30:24
|
On Mon, Aug 8, 2011 at 12:33 AM, Adam Retter <ad...@ex...> wrote:
> I have just studied the code, and if I understand it correctly then
> there are a couple of things that seem incorrect here. It early and I
> cant sleep.
>
> Dannes is the master of all things WebDAV, so he may be able to show
> us what we are misunderstanding.
>
> Your comment about the read-lock -- it seems to me that the finally
> resource lock release, only happens if isNullResource is set, yet when
> isNullResource is set, the resource is never read locked anyway as far
> as I can tell.
>
> IMHO, this function could be improved by being split into two, its too
> long and it takes two different actions, in the least it could call
> out to a function to handle the null resource path. This would make
> the code easier to understand and test.
>
> In its current state I think line 277 should be deleted, and also line
> 294, and this should fix the locking issue.
>
This was my first thought as well (and may very well be the correct one).
But I thought there might be a reason the resource is being unlocked before
the transct.commit(). But, I haven't spent any time in the transaction
system, so I really have no idea.
>
> But in addition it seems to me, that this function reports to WebDAV
> that resources have been locked, but this is not the case as it always
> unlocks the resource. I am not sure why this would be, but I would of
> imagined that the resource should remain locked until WebDAV unlocks
> it?
>
>
I think this is actually working correctly. The function puts a user lock
and a lockToken on the resource, which (from my understanding) is the
correct way to put a persistent (user level) lock on a document. What it's
releasing is the database READ_LOCK, which can block other processes that
try to read the resource.
>
>
> On 8 August 2011 03:22, Patrick Bosek <pat...@jo...> wrote:
> > Hi Everyone,
> >
> > After many hours of investigation I've found a locking situation in the
> > WebDAV module which causes database deadlocks. The problem (as I see it)
> is
> > that the webdav.methods.Lock.process() sets a READ_LOCK and has several
> > cases where it exits without releasing it:
> >
> >
> > -- webdav.methods.Lock.process() -- line 201:
> >
> > resource = broker.getXMLResource(path,
> > org.exist.storage.lock.Lock.READ_LOCK);
> >
> > ....
> >
> > -- webdav.methods.Lock.process() -- line 249: !!!!! As you can see in the
> > case where the resource is already locked, it exists without releasing
> it's
> > READ_LOCK
> >
> > // Check if Resource is already locked.
> > if( lock!=null && !lock.getName().equals(user.getName())
> ){
> > LOG.debug("Resource is locked.");
> > response.sendError(SC_RESOURCE_IS_LOCKED,
> > "Resource is locked by user "+ user.getName()
> > +".");
> > return;
> > }
> >
> > // Check for request fo shared lock.
> > if(lockToken.getScope() == LockToken.LOCK_SCOPE_SHARED) {
> > LOG.debug("Shared locks are not implemented.");
> >
> > response.sendError(HttpServletResponse.SC_NOT_IMPLEMENTED,
> > "Shared locks are not implemented.");
> > return;
> > }
> >
> > // Fill new Locktoken with new UUID
> > lockToken.createOpaqueLockToken();
> > resource.getMetadata().setLockToken(lockToken);
> > resource.setUserLock(user);
> >
> > // Make token persistant
> > TransactionManager transact =
> pool.getTransactionManager();
> > Txn transaction = transact.beginTransaction();
> > broker.storeXMLResource(transaction, resource);
> > //TOUNDERSTAND : this lock is released below (in the
> finally
> > clause)
> > //isn't it rather a user lock release attempt ?
> > // ?
> >
> > resource.getUpdateLock().release(org.exist.storage.lock.Lock.READ_LOCK);
> > !!!!! Here is where it is released when no one else has it locked
> > transact.commit(transaction);
> >
> >
> >
> > So, this is an issue which occurs in multi-user systems when two users
> try
> > to access the same document.
> >
> > My proposed fix is to simply add releases to the two return cases. I
> don't
> > really understand why the resource isn't just being unlocked in the
> finally
> > in all cases, but I'm guessing there is a reason to release it before
> > committing the transaction that I don't understand.
> >
> > My Fix:
> >
> > if( lock!=null && !lock.getName().equals(user.getName())
> ){
> > LOG.debug("Resource is locked.");
> > response.sendError(SC_RESOURCE_IS_LOCKED,
> > "Resource is locked by user "+ user.getName()
> > +".");
> >
> >
> > resource.getUpdateLock().release(org.exist.storage.lock.Lock.READ_LOCK);
> > return;
> > }
> >
> > // Check for request fo shared lock.
> > if(lockToken.getScope() == LockToken.LOCK_SCOPE_SHARED) {
> > LOG.debug("Shared locks are not implemented.");
> >
> > response.sendError(HttpServletResponse.SC_NOT_IMPLEMENTED,
> > "Shared locks are not implemented.");
> >
> >
> > resource.getUpdateLock().release(org.exist.storage.lock.Lock.READ_LOCK);
> > return;
> > }
> >
> >
> > I can provide a patch or simply commit this into the 1.4.x branch if
> > requested to do so by one of the core developers. But I wanted to ask
> first,
> > since there are things going on here that are above my head.
> >
> > Thoughts?
> >
> >
> > Cheers,
> >
> > --
> > Patrick Bosek
> > Jorsek Software
> > Cell (585) 820 9634
> > Office (877) 492 2960
> > Jorsek.com
> >
> >
> >
> ------------------------------------------------------------------------------
> > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> > The must-attend event for mobile developers. Connect with experts.
> > Get tools for creating Super Apps. See the latest technologies.
> > Sessions, hands-on labs, demos & much more. Register early & save!
> > http://p.sf.net/sfu/rim-blackberry-1
> > _______________________________________________
> > Exist-development mailing list
> > Exi...@li...
> > https://lists.sourceforge.net/lists/listinfo/exist-development
> >
> >
>
>
>
> --
> Adam Retter
>
> eXist Developer
> { United Kingdom }
> ad...@ex...
> irc://irc.freenode.net/existdb
>
--
Patrick Bosek
Jorsek Software
Cell (585) 820 9634
Office (877) 492 2960
Jorsek.com
|
|
From: Dannes W. <da...@ex...> - 2011-08-08 06:04:53
|
I need some time to study your proposed fix….. and understand the consequences. On 8 Aug 2011, at 3:22 , Patrick Bosek wrote: > I can provide a patch or simply commit this into the 1.4.x branch if requested to do so by one of the core developers. But I wanted to ask first, since there are things going on here that are above my head. -- Dannes Wessels eXist-db Open Source Native XML Database e: da...@ex... w: http://www.exist-db.org |
|
From: Adam R. <ad...@ex...> - 2011-08-08 04:33:37
|
I have just studied the code, and if I understand it correctly then
there are a couple of things that seem incorrect here. It early and I
cant sleep.
Dannes is the master of all things WebDAV, so he may be able to show
us what we are misunderstanding.
Your comment about the read-lock -- it seems to me that the finally
resource lock release, only happens if isNullResource is set, yet when
isNullResource is set, the resource is never read locked anyway as far
as I can tell.
IMHO, this function could be improved by being split into two, its too
long and it takes two different actions, in the least it could call
out to a function to handle the null resource path. This would make
the code easier to understand and test.
In its current state I think line 277 should be deleted, and also line
294, and this should fix the locking issue.
But in addition it seems to me, that this function reports to WebDAV
that resources have been locked, but this is not the case as it always
unlocks the resource. I am not sure why this would be, but I would of
imagined that the resource should remain locked until WebDAV unlocks
it?
On 8 August 2011 03:22, Patrick Bosek <pat...@jo...> wrote:
> Hi Everyone,
>
> After many hours of investigation I've found a locking situation in the
> WebDAV module which causes database deadlocks. The problem (as I see it) is
> that the webdav.methods.Lock.process() sets a READ_LOCK and has several
> cases where it exits without releasing it:
>
>
> -- webdav.methods.Lock.process() -- line 201:
>
> resource = broker.getXMLResource(path,
> org.exist.storage.lock.Lock.READ_LOCK);
>
> ....
>
> -- webdav.methods.Lock.process() -- line 249: !!!!! As you can see in the
> case where the resource is already locked, it exists without releasing it's
> READ_LOCK
>
> // Check if Resource is already locked.
> if( lock!=null && !lock.getName().equals(user.getName()) ){
> LOG.debug("Resource is locked.");
> response.sendError(SC_RESOURCE_IS_LOCKED,
> "Resource is locked by user "+ user.getName()
> +".");
> return;
> }
>
> // Check for request fo shared lock.
> if(lockToken.getScope() == LockToken.LOCK_SCOPE_SHARED) {
> LOG.debug("Shared locks are not implemented.");
>
> response.sendError(HttpServletResponse.SC_NOT_IMPLEMENTED,
> "Shared locks are not implemented.");
> return;
> }
>
> // Fill new Locktoken with new UUID
> lockToken.createOpaqueLockToken();
> resource.getMetadata().setLockToken(lockToken);
> resource.setUserLock(user);
>
> // Make token persistant
> TransactionManager transact = pool.getTransactionManager();
> Txn transaction = transact.beginTransaction();
> broker.storeXMLResource(transaction, resource);
> //TOUNDERSTAND : this lock is released below (in the finally
> clause)
> //isn't it rather a user lock release attempt ?
> // ?
>
> resource.getUpdateLock().release(org.exist.storage.lock.Lock.READ_LOCK);
> !!!!! Here is where it is released when no one else has it locked
> transact.commit(transaction);
>
>
>
> So, this is an issue which occurs in multi-user systems when two users try
> to access the same document.
>
> My proposed fix is to simply add releases to the two return cases. I don't
> really understand why the resource isn't just being unlocked in the finally
> in all cases, but I'm guessing there is a reason to release it before
> committing the transaction that I don't understand.
>
> My Fix:
>
> if( lock!=null && !lock.getName().equals(user.getName()) ){
> LOG.debug("Resource is locked.");
> response.sendError(SC_RESOURCE_IS_LOCKED,
> "Resource is locked by user "+ user.getName()
> +".");
>
>
> resource.getUpdateLock().release(org.exist.storage.lock.Lock.READ_LOCK);
> return;
> }
>
> // Check for request fo shared lock.
> if(lockToken.getScope() == LockToken.LOCK_SCOPE_SHARED) {
> LOG.debug("Shared locks are not implemented.");
>
> response.sendError(HttpServletResponse.SC_NOT_IMPLEMENTED,
> "Shared locks are not implemented.");
>
>
> resource.getUpdateLock().release(org.exist.storage.lock.Lock.READ_LOCK);
> return;
> }
>
>
> I can provide a patch or simply commit this into the 1.4.x branch if
> requested to do so by one of the core developers. But I wanted to ask first,
> since there are things going on here that are above my head.
>
> Thoughts?
>
>
> Cheers,
>
> --
> Patrick Bosek
> Jorsek Software
> Cell (585) 820 9634
> Office (877) 492 2960
> Jorsek.com
>
>
> ------------------------------------------------------------------------------
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> Exist-development mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-development
>
>
--
Adam Retter
eXist Developer
{ United Kingdom }
ad...@ex...
irc://irc.freenode.net/existdb
|
|
From: Patrick B. <pat...@jo...> - 2011-08-08 01:45:31
|
Update:
I may be reading this wrong, but does this else-case cause an unreleased
READ_LOCK on a collection?
-- webdav.methods.Lock.process() -- line 208:
if(resource == null) {
// No document found, maybe a collection
LOG.info("resource==null, document not found.");
collection = broker.openCollection(path,
org.exist.storage.lock.Lock.READ_LOCK);
if(collection == null){
LOG.info("collection==null, path does not point to
collection");
LOG.debug("Create document as NullResource");
createNullResource(user, request, response, path);
isNullResource=true;
} else {
String txt="Locking on collections not supported yet.";
LOG.debug(txt);
response.sendError(HttpServletResponse.SC_NOT_IMPLEMENTED, txt);
return;
}
On Sun, Aug 7, 2011 at 9:22 PM, Patrick Bosek <pat...@jo...>wrote:
> Hi Everyone,
>
> After many hours of investigation I've found a locking situation in the
> WebDAV module which causes database deadlocks. The problem (as I see it) is
> that the webdav.methods.Lock.process() sets a READ_LOCK and has several
> cases where it exits without releasing it:
>
>
> -- webdav.methods.Lock.process() -- line 201:
>
> resource = broker.getXMLResource(path,
> org.exist.storage.lock.Lock.READ_LOCK);
>
> ....
>
> -- webdav.methods.Lock.process() -- line 249:* !!!!! As you can see in the
> case where the resource is already locked, it exists without releasing it's
> READ_LOCK*
>
> // Check if Resource is already locked.
> if( lock!=null && !lock.getName().equals(user.getName()) ){
> LOG.debug("Resource is locked.");
> response.sendError(SC_RESOURCE_IS_LOCKED,
> "Resource is locked by user "+ user.getName()
> +".");
> return;
> }
>
> // Check for request fo shared lock.
> if(lockToken.getScope() == LockToken.LOCK_SCOPE_SHARED) {
> LOG.debug("Shared locks are not implemented.");
>
> response.sendError(HttpServletResponse.SC_NOT_IMPLEMENTED,
> "Shared locks are not implemented.");
> return;
> }
>
> // Fill new Locktoken with new UUID
> lockToken.createOpaqueLockToken();
> resource.getMetadata().setLockToken(lockToken);
> resource.setUserLock(user);
>
> // Make token persistant
> TransactionManager transact = pool.getTransactionManager();
> Txn transaction = transact.beginTransaction();
> broker.storeXMLResource(transaction, resource);
> //TOUNDERSTAND : this lock is released below (in the
> finally clause)
> //isn't it rather a user lock release attempt ?
> // ?
>
> resource.getUpdateLock().release(org.exist.storage.lock.Lock.READ_LOCK); *!!!!!
> Here is where it is released when no one else has it locked*
> transact.commit(transaction);
>
>
>
> So, this is an issue which occurs in multi-user systems when two users try
> to access the same document.
>
> My proposed fix is to simply add releases to the two return cases. I don't
> really understand why the resource isn't just being unlocked in the finally
> in all cases, but I'm guessing there is a reason to release it before
> committing the transaction that I don't understand.
>
> My Fix:
>
> if( lock!=null && !lock.getName().equals(user.getName()) ){
> LOG.debug("Resource is locked.");
> response.sendError(SC_RESOURCE_IS_LOCKED,
> "Resource is locked by user "+ user.getName()
> +".");
>
>
> resource.getUpdateLock().release(org.exist.storage.lock.Lock.READ_LOCK);
> return;
> }
>
> // Check for request fo shared lock.
> if(lockToken.getScope() == LockToken.LOCK_SCOPE_SHARED) {
> LOG.debug("Shared locks are not implemented.");
>
> response.sendError(HttpServletResponse.SC_NOT_IMPLEMENTED,
> "Shared locks are not implemented.");
>
>
> resource.getUpdateLock().release(org.exist.storage.lock.Lock.READ_LOCK);
> return;
> }
>
>
> I can provide a patch or simply commit this into the 1.4.x branch if
> requested to do so by one of the core developers. But I wanted to ask first,
> since there are things going on here that are above my head.
>
> Thoughts?
>
>
> Cheers,
>
> --
> Patrick Bosek
> Jorsek Software
> Cell (585) 820 9634
> Office (877) 492 2960
> Jorsek.com
>
>
--
Patrick Bosek
Jorsek Software
Cell (585) 820 9634
Office (877) 492 2960
Jorsek.com
|
|
From: Patrick B. <pat...@jo...> - 2011-08-08 01:22:48
|
Hi Everyone,
After many hours of investigation I've found a locking situation in the
WebDAV module which causes database deadlocks. The problem (as I see it) is
that the webdav.methods.Lock.process() sets a READ_LOCK and has several
cases where it exits without releasing it:
-- webdav.methods.Lock.process() -- line 201:
resource = broker.getXMLResource(path,
org.exist.storage.lock.Lock.READ_LOCK);
....
-- webdav.methods.Lock.process() -- line 249:* !!!!! As you can see in the
case where the resource is already locked, it exists without releasing it's
READ_LOCK*
// Check if Resource is already locked.
if( lock!=null && !lock.getName().equals(user.getName()) ){
LOG.debug("Resource is locked.");
response.sendError(SC_RESOURCE_IS_LOCKED,
"Resource is locked by user "+ user.getName()
+".");
return;
}
// Check for request fo shared lock.
if(lockToken.getScope() == LockToken.LOCK_SCOPE_SHARED) {
LOG.debug("Shared locks are not implemented.");
response.sendError(HttpServletResponse.SC_NOT_IMPLEMENTED,
"Shared locks are not implemented.");
return;
}
// Fill new Locktoken with new UUID
lockToken.createOpaqueLockToken();
resource.getMetadata().setLockToken(lockToken);
resource.setUserLock(user);
// Make token persistant
TransactionManager transact = pool.getTransactionManager();
Txn transaction = transact.beginTransaction();
broker.storeXMLResource(transaction, resource);
//TOUNDERSTAND : this lock is released below (in the finally
clause)
//isn't it rather a user lock release attempt ?
// ?
resource.getUpdateLock().release(org.exist.storage.lock.Lock.READ_LOCK); *!!!!!
Here is where it is released when no one else has it locked*
transact.commit(transaction);
So, this is an issue which occurs in multi-user systems when two users try
to access the same document.
My proposed fix is to simply add releases to the two return cases. I don't
really understand why the resource isn't just being unlocked in the finally
in all cases, but I'm guessing there is a reason to release it before
committing the transaction that I don't understand.
My Fix:
if( lock!=null && !lock.getName().equals(user.getName()) ){
LOG.debug("Resource is locked.");
response.sendError(SC_RESOURCE_IS_LOCKED,
"Resource is locked by user "+ user.getName()
+".");
resource.getUpdateLock().release(org.exist.storage.lock.Lock.READ_LOCK);
return;
}
// Check for request fo shared lock.
if(lockToken.getScope() == LockToken.LOCK_SCOPE_SHARED) {
LOG.debug("Shared locks are not implemented.");
response.sendError(HttpServletResponse.SC_NOT_IMPLEMENTED,
"Shared locks are not implemented.");
resource.getUpdateLock().release(org.exist.storage.lock.Lock.READ_LOCK);
return;
}
I can provide a patch or simply commit this into the 1.4.x branch if
requested to do so by one of the core developers. But I wanted to ask first,
since there are things going on here that are above my head.
Thoughts?
Cheers,
--
Patrick Bosek
Jorsek Software
Cell (585) 820 9634
Office (877) 492 2960
Jorsek.com
|
64 messages has been excluded from this view by a project administrator.
