Programmer's Guide:
Programming Guidelines and Recommendations
Building ASP Pages using eRoom SAAPI
Never hold onto eRoom objects
or interfaces across ASP page requests. That is, don't store objects or
interfaces in session or application variables. Always release an object
or interface before the end of an ASP page.
Pages should be run from
a virtual root that is configured to run in the IIS process along with
eRoom. Ensure that the application protection is set to low (IIS Process).
In some
cases, when using SAAPI in ASP, you might need to ensure that eRoom's
storage subsystem remains loaded. Do this by storing an IERUApplication
(eRoom.Application) either in the user's session, or in an ASP application
object in global.asa. Note that this is the only
eRoom object/interface that should ever be stored on the session or in
application-scope objects. This is to ensure that database connections
are not held open. (See example)
eRoom's
IIS virtual roots must allow anonymous login and not contain basic authentication
or Windows Integrated Security. This includes any directories below /eRoomASP/Extensions/,
as they are part of the eRoom application.
Building Visual Basic .DLLs
When building Visual Basic .DLLs for IIS or COM+ environments, you should
always ensure that the Unattended Execution and Retain in Memory options
are selected. If these options are not selected, the Visual
Basic runtime unloads custom and runtime .DLLs unexpectedly, which causes
the computer to stop responding (crash or hang) under some multithreaded
scenarios.
Follow these steps to enable these options in your Visual Basic project:
1. From the Project menu, select Project Properties.
2. On the General tab, select the Unattended Execution and Retain In
Memory checkboxes.
The Unattended Execution option is not available if the project contains
any user interface elements, such as forms or controls. The Retain in
Memory option is not available if Unattended Execution is not selected.
Prior to Service Pack 3 for Visual Studio 6.0, it was possible to receive
an access violation during process shutdown with Retain in Memory enabled.
This has been fixed Visual Studio 6.0, Service Pack 3 or later.
Releasing Deleted Objects
If you delete an object through SAAPI code, that object is not deleted
from the eRoom Server until all references to it are released. This
includes any collections in your application that may contain the deleted
item. Your application may behave unexpectedly if you try to create
another item by the same name without releasing all references to the
deleted item. The following example illustrates this error.
Sub Main
Const const_FacilityName = "sample"
Const const_TemplateRoomPrefix = "template_"
Dim App
Dim facility
Dim rooms
Dim room
Set App = CreateObject("eRoom.Application")
Set facility = App.GetFacility(const_FacilityName)
Set rooms = facility.rooms
'# Find all rooms that start with the phrase "template_"
Make a fresh copy of those rooms.
For Each room In rooms
If lcase(left(room.urlname,
Len(const_TemplateRoomPrefix))) = lcase(const_TemplateRoomPrefix) Then
'##
Recreate room; (See explanation below.)
Call
RecreateTemplateRoom(facility, room, Mid(room.urlname, Len(const_TemplateRoomPrefix)
+ 1) )
End If
Next
End Sub
Sub RecreateTemplateRoom(facility, room, roomname)
'# The roomname variable contains the name of the template
room with the "template_" prefix removed.
Dim newroom
Set newroom = Nothing
Set newroom = facility.GetRoomByName(roomname)
'# If a room by that name already
exists, then delete it.
If Not (newroom Is Nothing) Then
newroom.Delete
Set newroom
= Nothing
End If
'# More code to recreate the room based on the template
room.
'# ...
End Sub
In the RecreateTemplateRoom
subroutine, we set the newroom
variable to Nothing
after deleting the room, releasing that reference to the object. However,
there is a second reference to that room inside of the rooms
collection variable in the Main subroutine. Because the rooms
collection has not yet been released, the room that was referenced by
the newroom
variable has not been deleted from the eRoom Server. This will create
unexpected behavior if you were to try to create a room of the same name
as the deleted room. |