Actually, I remember a year or so ago one user posted quite a few
messages to the user list regarding getting LDAP to work with
authentication. I believe she wrote up something on the wiki. I'd
search the mail archives and look in the wiki before you go hiring anyone.
And FWIW, I have quite a bit of LDAP experience. It is actually pretty
easy in Java. I wrote a "Preferences" component for my employer that
has an API very similar to the JDK 1.4 Preferences API. It is written in
such a way that the "DataStore" is pluggable. We currently support LDAP,
RDBMS, directory/file, and read-only XML data stores. The File
datastore is the fastest but isn't useful in production (our developers
use it quite a bit though). LDAP is by far the fastest for production use.
Ralph
Gerry Kaplan wrote:
Thanks much for your feedback.
In fact, my current design creates a separate xml file for each user, and I
started wavering on whether it was better to keep them all in one file or
not. Ultimately, I will use an LDAP. I need to find a Cocoon consultant who
has experience with using an LDAP, as I have limited LDAP experience. This
is the only time in the app that concurrency is an issue. An LDAP would be a
great solution to user management for sure.
Thanks again!
Gerry
-----Original Message-----
From: Ralph Goers [mailto:[EMAIL PROTECTED]
Sent: Monday, September 12, 2005 12:32 AM
To: [email protected]
Subject: Re: Concurrency in flowscript
To make a long story short, Cocoon would be like any other application in
your scenario. You have to provide the synchronization into the pipeline.
You have to add the transaction support so that the second user would be
informed that the document had changed by the first user while he was
editing it.
However, as far as I can see this has nothing to do with the forms. I'm
pretty sure they will execute independently as each flow will create its own
form object.
Does your design really call for a single users.xml document? I just can't
imagine that scaling very well - it would get rather huge. I could imagine
each user having an entry in a database table or in an LDAP repository and
every user getting their own user.xml document though. That wouldn't have
any of the problems you are mentioning. I seem to recall some of the
samples using a users.xml to look up a user during authentication, but those
are just sample pipelines and not necessarily meant to be a production
design. You can use other mechanisms to perform the authentication.
Ralph
Gerry Kaplan wrote:
I'm curious about how Cocoon handles concurrency under the following
circumstances.
Let's say that a pipeline calls a flowscript function to show a form.
When the user completes the form and submits, the flowscript reads an
XML document, then adds the data from the form to the document, and
then re-saves the document.
What would happen if, at the exact same moment, another user called
upon the same pipeline and displayed the form, then submitted. But the
first user's save hasn't occurred yet. When the 2nd user saves the
document, it will overwrite any changes that the first user added.
The real scenario is a self-registration form. The application keeps a
single XML document that contains a "user" node for each user. When the
user self registers, their entries are added into the users.xml
document. Does Cocoon allow multiple instances of the same form to execute
simultaneously?
Or is there a "synchronized" type of keyword in flowscript that would
prevent both users from reading/updating/writing the same XML document?
Gerry
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
