[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: JLDAP vs. JNDI



David,
    You can very easily do such kind of stuff using JLDAP API.  The
sample code  at:- 

http://developer.novell.com/ndk/doc/samplecode/jldap_sample/asynchronous/Searchas.java.html


 demonstartes how you can do this using JLDAP classes. You can also set
the batchSize using LDAPSearchConstraint object, which will provide you
a control over the size of result after which you want getResponse() to
return.



Regards
Sunil.


>>> "David Parker" <david.parker@rocketsoftware.com> 1/9/2004 2:41:15
AM >>>
Thanks.

Well, that's what I thought, too, but the problem is that the executing
thread is still not going to get any data back from the search until all
the results are returned from the server, as far as I can tell.

The concern is not so much to allow the client to do other operations
while the search is executing, but to be able to display each result as
it is returned from the server, i.e., to start displaying results one at
a time before all results have been returned. So, even though we execute
the search in a separate thread, in practice the user is going to be
waiting for the results anyway, and with JNDI the first result is not
going to be available until ALL the results are returned from the
server. At least, that's the way I interpret the behavior I'm seeing...

Does the distinction I'm making make sense? I am extrapolating from the
way the LDAP C API works. Just executing the JNDI search in a separate
thread doesn't seem to solve my problem, but it's entirely possible I'm
not understanding either the JNDI or the C API properly!

- DAP


> > we discovered that there doesn't seem to be any way to do 
> an asynchronous search.
> You really do not need it. Just perform search in a thread different
> from the Swing worker thread - and simple JNDI synchronous 
> searches will
> do.
> 
> I do not know about JLDAP but I know Java a bit. Multithreading is
the
> best solution for problems like this. Ever did JDBC queries from
GUI?
> Same story.
> 
> HTH,
> 
> -- 
> Sergey
> 
> 
>