Hi Jocelyn,

1. It's very hard to change locking mechanism. It won't be implemented in
the near future (.
2. It's definitely ok.
3. Yes:

Can you try at least to rewrite your queries so that locks are acquired in
the same order (collections are read/updated in the same order in all
queries)? In this case there shouldn't be deadlocks.

Send us full description of your transactions and full event logs. Maybe we
can optimize something.

Which driver do you use now?

Ivan



On Sat, Mar 9, 2013 at 8:09 PM, Jocelyn Raymond <jraym...@ualberta.ca>wrote:

> Hi Sedna Team,
> Sorry for the long email.
> We have been having some serious problem in our production database with
> "(SE4703) The transaction is a victim of deadlock resolution procedure."
> We have the latest sedna release on Linux Red Hat.
>
> Our situation is as follow:
> 1. Our main entity is an "Award Competition" which is split into several
> smaller entities kept into separate sedna collections.
> 2. Our smaller entities are: collection('personal-info'),
> collection('student-payload'), collection('activity') and so on.  Each
> entities are quite small (average of 10-20 tags with fairly short text
> nodes).
> 3. So one person applying to one "Award Competition" will need to do a
> "write" to all those collections.
> 4. We also need to "write" all those xml documents in one transaction
> (write all or rollback).
> 5. We know that, in order to write to sedna, the transaction need to
> acquire a lock on the "collection" and not the "document".
> 6. We have thousands of people applying and what we think is happening is
> that one person gets the lock for the collection('personal-info') and
> another person gets the lock for collection('student-payload') which result
> in the deadlock i.e. the first person having the lock for
> collection('personal-info'), in the same transaction, is trying to acquire
> the lock for collection('student-payload') but can't because it is used by
> the second person transaction and vice versa.
>
> The questions are:
> 1. Is it possible to have sedna locking on document instead of collection?
>  (probably not but worth to ask).
> 2. We tried to make our transaction as small as possible but need to
> "save" to several collections in one transactions.
> 3. Any suggestions?
>
> We are in the process to try the XQJ driver but we don't think it will
> resolve our deadlock situation.  Let me know if you think XQJ may give us
> better result.
> As such, I have a question in regard using XQJ:
> Would this be valid xquery with sedna (we want to "LOAD" a new document):
> XQPreparedExpression expression = conn.prepareExpression("declare variable
> $collection external; " +
>                                                          "declare variable
> $docname external; " +
>                                                          "declare variable
> $xmldoc external; " +
>                                                          "UPDATE insert
> $xmldoc INTO doc($docname,$collection)";
> //
> String collection = "activity";
> String docname    = "unique_name_goes_here";
> String xmldoc     = "<activity>...</activity>";
> // Or Document xmldoc = builder.newDocument()...;
> expression.bindDocument(new QName("xmldoc"), xmldoc, null, null); // not
> sure of the last two parameters
> expression.bindString(new QName("docname"), docname, null, null);
> expression.bindString(new QName("collection"), collection, null, null);
>
> The question is "expression.bindDocument(...)"  Is it the right thing to
> do to LOAD new document or should we use "expression.bindItem(...)" or
> "expression.bindSequence(...)" or
> "expression.bindNode(...)" or
> "expression.bindObject(...)"
>
> Note:  We use JAXB.  Can we pass JAXB as a "bind???" method?
>
>
>
> Entities:
> Here is an example of entity model we have for collection('activity')
> <activity type="university" id="1360861690701">
>   <organization-name>female basketball team</organization-name>
>   <position-title>player</position-title>
>   <date attending="" end="2012-10-25" start="2012-05-03"/>
>   <time-commitment-per-week>120</time-commitment-per-week>
>   <description>This is a sample description that can contain up to 300
> words.</description>
> </activity>
>
> Thank you very much for your input,
> Jocelyn Raymond
> --
> Data Architect / Development Manager
> Information Systems
> Office of the Registrar
> University of Alberta
> 780.492.3874
>
> *** Please note: Our unit has moved to SAB-1-26. Other moves will be
> happening within the Office of the Registrar over the coming weeks. To keep
> updated, please visit our 
> website<http://www.registrarsoffice.ualberta.ca/Faculty-and-Staff/Office-Move.aspx>.
> *
>
>
>
> ------------------------------------------------------------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
> _______________________________________________
> Sedna-discussion mailing list
> Sedna-discussion@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sedna-discussion
>
>
------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
endpoint security space. For insight on selecting the right partner to 
tackle endpoint security challenges, access the full report. 
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
Sedna-discussion mailing list
Sedna-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sedna-discussion

Reply via email to