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
