Questions about containers, servlets, transactions, and sessions

[Adrian Crum]

I created a simple WebDAV server to enable writable calendars in the
iCalendar integration. I'm finishing up the code and I have a few
outstanding issues to take care of.

I'm a little fuzzy on application servers and servlets, so I could use
some advice and guidance.

 From what I understand, the container takes care of transactions, so I
shouldn't have to worry about transactions in my servlet code. Is that
correct?

WebDAV does not recognize sessions - no information is persisted across
requests. If that's the case, what would be a good strategy for user log
in/log out? To be more specific, a user updates their calendar. A WebDAV
request is made, the user is logged into OFBiz, the work effort updates
are made, and then...? If the user is logged out afterwards, then that
would also log them out of any browser sessions they have going.

Any help would be greatly appreciated!

-Adrian

[David E. Jones-2]

On Jun 18, 2009, at 9:51 AM, Adrian Crum wrote:

> I created a simple WebDAV server to enable writable calendars in the  
> iCalendar integration. I'm finishing up the code and I have a few  
> outstanding issues to take care of.
>
> I'm a little fuzzy on application servers and servlets, so I could  
> use some advice and guidance.
>
> From what I understand, the container takes care of transactions, so  
> I shouldn't have to worry about transactions in my servlet code. Is  
> that correct?

Do you mean the Servlet container? If so no, the servlet stuff in  
general doesn't know anything about or do anything with transactions  
(unless there is some fancy new thing I'm not aware of). The OFBiz  
framework does this at various points, which is probably what you're  
used to. The main 2 places that OFBiz manages transactions are with  
screen widget rendering, and with service engine calls. Even request  
events in OFBiz don't automatically have transaction management, so if  
you want transactions there (and you aren't calling a service) then  
you have to write tx demarcation code (with the proper try/finally  
stuff, etc... and OFTEN this is done incorrectly when it is done  
manually like this).

> WebDAV does not recognize sessions - no information is persisted  
> across requests. If that's the case, what would be a good strategy  
> for user log in/log out? To be more specific, a user updates their  
> calendar. A WebDAV request is made, the user is logged into OFBiz,  
> the work effort updates are made, and then...? If the user is logged  
> out afterwards, then that would also log them out of any browser  
> sessions they have going.

By "does not recognize sessions" do you mean that it doesn't/can't  
pass around the jsessionid? In that case all it means is that each  
request gets a new session, and that session is used only for that  
request. The session will time out as normal, and will (hopefully!)  
remain dormant as long as it is valid.

If there is no session passed and the requests run in their own  
sessions, then it won't have an effect on other sessions even from the  
same client. About the logout, if the user is explicitly logged out  
then it will set the logged out flag in the database and that will  
cause requests to existing sessions from that user to log them out. If  
there is no explicit logout you don't have to worry about it. The  
session will eventually expire and then the user is no longer "logged  
in" as the session doesn't exist. If you are writing code to do this  
manually, just remove the userLogin attribute from the session, or  
even invalidate the session.

-David

[Adrian Crum]

David,

Thank you very much for your help! Comments inline.

David E Jones wrote:

> Do you mean the Servlet container? If so no, the servlet stuff in
> general doesn't know anything about or do anything with transactions
> (unless there is some fancy new thing I'm not aware of). The OFBiz
> framework does this at various points, which is probably what you're
> used to. The main 2 places that OFBiz manages transactions are with
> screen widget rendering, and with service engine calls. Even request
> events in OFBiz don't automatically have transaction management, so if
> you want transactions there (and you aren't calling a service) then you
> have to write tx demarcation code (with the proper try/finally stuff,
> etc... and OFTEN this is done incorrectly when it is done manually like
> this).

I'll need to copy the Tx management code from there then. Let's hope the
existing code is done correctly! ;-)

>> WebDAV does not recognize sessions - no information is persisted
>> across requests. If that's the case, what would be a good strategy for
>> user log in/log out? To be more specific, a user updates their
>> calendar. A WebDAV request is made, the user is logged into OFBiz, the
>> work effort updates are made, and then...? If the user is logged out
>> afterwards, then that would also log them out of any browser sessions
>> they have going.
>
> By "does not recognize sessions" do you mean that it doesn't/can't pass
> around the jsessionid?

No, WebDAV clients don't know about sessions. Although WebDAV is based
on HTTP, the client software isn't necessarily a browser. It could be
website authoring software, or a calendar program, or even Windows Explorer.

> In that case all it means is that each request
> gets a new session, and that session is used only for that request. The
> session will time out as normal, and will (hopefully!) remain dormant as
> long as it is valid.
>
> If there is no session passed and the requests run in their own
> sessions, then it won't have an effect on other sessions even from the
> same client. About the logout, if the user is explicitly logged out then
> it will set the logged out flag in the database and that will cause
> requests to existing sessions from that user to log them out. If there
> is no explicit logout you don't have to worry about it. The session will
> eventually expire and then the user is no longer "logged in" as the
> session doesn't exist. If you are writing code to do this manually, just
> remove the userLogin attribute from the session, or even invalidate the
> session.

Invalidating the session sounds like a good approach.

-Adrian