I am using the RDBMS store and it has the same problem with respect to role and group membership. The membership list is stored as a single property instead of a collection. This causes scalability problems for large groups/roles and limits the databases ability to do efficient membership searches. For RDBMS, Slide only works efficiently when all of this information can be pulled into memory. ________________________________
From: Michael Oliver [mailto:[EMAIL PROTECTED] Sent: Friday, November 04, 2005 6:07 PM To: Slide Dev Mailing List Subject: Performance Hi gents, I just have a quick question on design or architecture related to Slide 2.1 and performance. I have been using and developing on slide now since before version 2.0 and have even written some tutorials for slide on IBM DeveloperWorks. I say this only so a responder won't waste time on trivialities. Now let me start by saying there are many ways to skin a cat and I am not trying to be critical of something I hold so highly. However there are a few things that bother me about the design and lead to what I believe are bottlenecks in scaling slide to more users and more kinds of implementations built on slide. One is the practice of storing a list of child nodes in the metadata of a collection node...seems like a waste to me. For example on the filesystem and therefore with the TxFile* stores, the list of children doesn't need to be stored in the metadata (as far as I can tell) because it is readily available in the file object for the folder. Opening, reading, inserting, and writing the collection's .def.xml (or the equivalent in the db) and the potential for deadlocks, contention and conflict with two or more users adding children at the same time to the same collection seems intuitively obvious. So why do it? Similarly, the 'group-member-set' for roles while not a factor in performance, seems awkward and cumbersome compared to a users collection and children. I mentioned this before and got "they aren't the same" and while that is certainly true logically the members of a role are not different than the members of a collection of users. Adding a user by simply doing a mkcol under /slide/users/ makes perfect sense, but so would simply doing a mkcol under /slide/roles/ for a username to be added to a role. Simple and consistent. If this august group's response is, Ok why don't you volunteer, I would say, ok I will. I will contribute a patch for the TxFileDescriptorsStore/XMLResourceDescriptor to fix the handling of collections metadata which I believe is the biggest problem and if that is received well I will contribute more. <http://www.alariussystems.com> Highly Cohesive and Loosely Coupled <http://mikeoliveraz.blogspot.com> Mike Oliver CTO Alarius Systems LLC 6800 E. Lake Mead Blvd Apt 1096 Las Vegas, NV 89156 <http://maps.yahoo.com/py/maps.py?Pyt=Tmap&addr=6800+E.+Lake+Mead+Blvd&c sz=Las+Vegas%2C+NV+89156&country=us> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> http://www.alariussystems.com/ <http://www.alariussystems.com/> tel: fax: mobile: (702)953-8949 (702)974-0341 (518)378-6154 Add me to your address book... <https://www.plaxo.com/add_me?u=25769982367&v0=355403&k0=305933374> Want a signature like this? <http://www.plaxo.com/signature>
