Jose,
A stateless session bean should not affect ur user object. The statefull
session bean will have a ldap connection object at class member which will
be an open connection. The user object may call getConnection and
closeConnections methods on this bean. Of course, u will have to synchornize
access to these methods so that getConnection is not allowed while some
client is using the connection.
In methods ejbCreate and getConnection, u will have to check if the
connection is open, otherwise re-connect. This is to handle the connection
being timed out between requests by clients.
This (checking for closed connection) can also be used in ur existing user
object to eliminate the problem of connections timing out or making a new
connection in ejbLoad.
Regards,
Amish
----- Original Message -----
From: "Jose González Gómez" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, February 05, 2001 2:19 PM
Subject: Re: Reading LDAP data with EJBs
Carlos,
Doing a query every n seconds imply creating threads inside an ejb
container, something I think is strictly forbidden... am I wrong?
Regards
Jose
Carlos Otero Barros wrote:
> Hi Jose;
>
>> what do we gain with this approach? Can we maintain an
>> open connection between calls to the session bean?
>
>
> You must reuse the Session Bean in a regular way
> (lookup/create/businessmethod) but the Session Bean will be persistently
> connected to LDAP. The reconection and rebinding time is what you want to
> avoid.
>
>> I think LDAP connections timeout, so the management of this
>> connection wouldn't be trivial... am I wrong?
>
>
> Couldn´t you avoid this problem doing a simple query every n seconds from
> within the Stateless Session Bean?
>
> Regards.
>
> ----- Original Message -----
> From: "Jose González Gómez" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, February 02, 2001 7:23 PM
> Subject: Re: Reading LDAP data with EJBs
>
>
>> Carlos,
>>
>> The problem here is that we have modeled user as a domain object.
>> Swtching to a representation with stateless session bean could be a real
>> headache. Anyway, what do we gain with this approach? Can we maintain an
>> open connection between calls to the session bean? Anyway, if we can do
>> this, I think LDAP connections timeout, so the management of this
>> connection wouldn't be trivial... am I wrong?
>>
>> Regards
>> Jose
>>
>> Carlos Otero Barros wrote:
>>
>>> Hi Jose;
>>>
>>> You could build a Stateless Session Bean acting as a LDAP connector,
>>
> with
>
>>> methods to retrieve information from LDAP database using JNDI. A
>>
> Stateless
>
>>> Session Bean is a common resource per appserver so you will not have a
>>
> big
>
>>> ammount container traffic.
>>>
>>> Regards.
>>>
>>> ----- Original Message -----
>>> From: "Jose González Gómez" <[EMAIL PROTECTED]>
>>> To: <[EMAIL PROTECTED]>
>>> Sent: Friday, February 02, 2001 6:26 PM
>>> Subject: Reading LDAP data with EJBs
>>>
>>>
>>>> Hi there,
>>>>
>>>> I have an ejb named User that models an user interacting with my
>>>> application. I need this as the actions this user may do in the
>>>> application depend on his position in a directory I access through
>>>
> LDAP.
>
>>>> I keep some info I need about the user in a database, as this info is
>>>> not in the directory. This way the bean encapsulates all the needed
>>>> access to LDAP and database.
>>>>
>>>> My problem is that in ejbLoad I need to connect to LDAP and
>>>
> database,
>
>>>> and in ejbStore I connect only to the database, as the info in LDAP
>>>
> will
>
>>>> never be changed in my application. I get the connections to the
>>>> database from the connection pool of my app server, but there's no
>>>> connection pooling for LDAP connnections, so the ejbLoad operation
>>>
> takes
>
>>>> a lot of time in making this connection time after time.
>>>>
>>>> What could I do? Should I make my own connection pooling mechanism
>>>> for LDAP? Is this possible under J2EE? Any other ideas about this?
>>>>
>>>> Thanks
>>>> Jose
>>>>
>>>>
>
===========================================================================
>
>>>> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
>>>
>>> body
>>>
>>>> of the message "signoff EJB-INTEREST". For general help, send email to
>>>> [EMAIL PROTECTED] and include in the body of the message "help".
>>>>
>>>>
>
===========================================================================
>
>>> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
>>
> body
>
>>> of the message "signoff EJB-INTEREST". For general help, send email to
>>> [EMAIL PROTECTED] and include in the body of the message "help".
>>>
>
===========================================================================
>
>> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
>
> body
>
>> of the message "signoff EJB-INTEREST". For general help, send email to
>> [EMAIL PROTECTED] and include in the body of the message "help".
>>
>>
>
>
===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help"..
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
