EOF-Using EOF-Context and Database Locking

1

|=(((

2

Contents

)))

|(((

)))

== Overview ==

Errors in locking your editing context (shared editing contexts or not) will cause your instance to deadlock. This is one of the most vexing problems.

11

12

//Do you have to lock & unlock the editing context only when you are using a stateless section (directActions) of your application or do you have to lock & unlock it in state as well? What about the defaultEditingContext, does that need locking & unlocking too?//

13

14

If your sessions only use the default editing context, you don't worry about locking.

15

16

//Also, manually locking/unlocking objects is error prone. And the resulting errors are the most difficult to fix since they only occur randomly on heavy load. I really feel that WebObjects should use Java synchronization to ensure safe access without requiring manual coding. But this would probably mean a considerable rework of WebObjects//

17

18

I used to think along the same lines, but it turns out this would introduce one hell-uv-a-lot of overhead. You'd have a performance situation not unlike the original Java collections (BAD). If you can acquire one lock and then plow through EC and EO API at will until unlock, you really save some cycles. I'm sure there are others more enlightened here that can elaborate or correct me here; but this is my impression.

19

20

BTW: I tend to create extra ECs at the Session level and do the locking and unlocking in the Session awake and sleep. The request handler prevents more than one request from getting access to a Session at a time; and you are guaranteed that Session awake and sleep trigger just once per request cycle. That's not true of component awake and sleep calls. You have a greater potential for a deadlock if you do the lock/unlock at the component level:

21

22

Transaction starts on one page (lock), then instead of returning that page after action, you create another page (potential lock again, deadlock).

23

24

The only tricky thing I've run into is if your app uses Long Running Request Page. That's a case where you get multiple request/responses as viewed by the session over one logical "request". That is, the status page will be reloading, but your background job is busy doing its thing continuously. If it's busy using a EC that is locking and unlocking at the session awake/sleep you wouldn't get very far without complaints. So in these cases, if a user enters such a page AND is using a EC, I disable the automatic session lock/unlock for that EC until the job is over. Or I create a EC used strictly for the background job.

=== David LeBer ===

In general you are better to lock EC's in the session (if you've got one) rather than the component.

29

30

As that is the usual approach, there are a couple of solutions to implement that for you:

31

32

* [[MultiECLockManager>>url:http://wocode.com/cgi-bin/WebObjects/WOCode.woa/1/wa/ShareCodeItem?itemId=301||shape="rect"]]

33

* [[Project Wonder's ERXEC>>url:http://wonder.sourceforge.net/javadoc/er/extensions/ERXEC.html||shape="rect"]]

34

35

=== Jonathan Rochkind ===

36

37

Note: One very handy (if I do say so myself) reusable solution for locking ECs you create (not neccesary for session default EC) can be found at: [[http:~~/~~/WOCode.com/cgi-bin/WebObjects/WOCode.woa/wa/ShareCodeItem?itemId=301>>url:http://WOCode.com/cgi-bin/WebObjects/WOCode.woa/wa/ShareCodeItem?itemId=301||shape="rect"]]

=== Anjo Krank ===

One thing to watch out for is that EC locking on the page's awake() and sleep() doesn't really work, because awake may be called more often than sleep. This means that normally you can't use DirectToWeb because it does just that. However, ProjectWonder has an editing context factory, an automatically locking and unlocking EC subclass and a lock manager that will relaese all locks when the application sleeps.

42

43

This works nicely with long response pages, provided that you don't use the session's editing context in the long running task.

44

45

== Locking in a DirectAction ==

46

47

//If i call session().defaultEditingContext() from within a DirectAction, I'm currently defensively locking it. Do I need to, or does it follow the same (automatic) locking rules as in a normal WOComponent?//

=== Anjo Krank ===

You don't need to lock it.

52

53

But anyway, doing sth like:

public WOActionResults someAction() {

58

WOActionResults page = pageWithName("Foo");

59

session().defaultEditingContext().lock;

try {

...

} finally {

session().defaultEditingContext().unlock;

}

return page;

}

isn't sufficient, as the appendToResponse phase only occurs **after** the page is returned and faults could still get fired there... so when you create an EC there instead of using the session EC, you still have to lock it in the component.

=== Chuck Hill ===

Here is another way to handle this:

public WOActionResults someAction() {

79

WOComponent page = pageWithName("Foo");

80

WOResponse response;

81

session().defaultEditingContext().lock;

82

try {

83

...

84

response = page.generateResponse().

85

} finally {

86

session().defaultEditingContext().unlock;

}

return response;

}

The call to generateResponse before the unlock ensures that appendToResponse is called while the EC is locked and that all the faults are fired in a safe state.

94

95

=== Robert Walker ===

96

97

I generally avoid using the session's default editing context within direct actions. A call to session().defaultEditingContext() will create a session, even if you don't actually need one. It can be more efficient to use a new editing context and lock it as necessary, since this will not cause unnecessary sessions to be created.

98

99

== Tracking EOEditingContext Locks ==

100

101

Project WOnder's ERXEC provides extensive logging facilities for tracking EOEditingContext locks. If you are not interested in using Project WOnder, there are several other ways:

102

103

You can display the stack trace of editingcontext locking warnings with the Launch Argument:

-NSDebugLevel 2 -NSDebugGroups 18

This will give you some information but there is a better way. You need to sub-class EOEditingContext like this:

112

113

=== LockErrorScreamerEditingContext ===

// LockErrorScreamerEditingContext.java

118

//

119

120

// by Jonathan 'Wolf' Rentzsch (jon at redshed dot net)

121

// enhanced by Anthony Ingraldi (a.m.ingraldi at larc.nasa.gov)

122

//

123

// Thu Mar 28 2002 wolf: Created.

124

// Thu Apr 04 2002 wolf: Made NSRecursiveLock-aware by Anthony.

125

// Thu Jun 22 2003 wolf: Made finalizer-aware. Thanks to Chuck Hill.

126

127

import com.webobjects.eocontrol.*;

128

import com.webobjects.foundation.*;

129

import java.io.StringWriter;

130

import java.io.PrintWriter;

131

132

public class LockErrorScreamerEditingContext extends EOEditingContext {

133

private String _nameOfLockingThread = null;

134

private NSMutableArray _stackTraces = new NSMutableArray();

135

136

public LockErrorScreamerEditingContext() {

super();

}

public LockErrorScreamerEditingContext(EOObjectStore parent) {

super(parent);

}

public void lock() {

String nameOfCurrentThread = Thread.currentThread().getName();

146

if (_stackTraces.count() == 0) {

147

_stackTraces.addObject(_trace());

148

_nameOfLockingThread = nameOfCurrentThread;

149

//NSLog.err.appendln("+++ Lock number (" + _stackTraces.count() + ") in " + nameOfCurrentThread);

150

} else {

151

if (nameOfCurrentThread.equals(_nameOfLockingThread)) {

152

_stackTraces.addObject(_trace());

153

//NSLog.err.appendln("+++ Lock number (" + _stackTraces.count() + ") in " + nameOfCurrentThread);

154

} else {

155

NSLog.err.appendln("!!! Attempting to lock editing context from " + nameOfCurrentThread

156

+ " that was previously locked in " + _nameOfLockingThread);

157

NSLog.err.appendln("!!! Current stack trace: \n" + _trace());

158

NSLog.err.appendln("!!! Stack trace for most recent lock: \n" + _stackTraces.lastObject());

}

}

super.lock();

}

public void unlock() {

165

super.unlock();

166

if (_stackTraces.count() > 0)

167

_stackTraces.removeLastObject();

168

if (_stackTraces.count() == 0)

169

_nameOfLockingThread = null;

170

String nameOfCurrentThread = Thread.currentThread().getName();

171

//NSLog.err.appendln("--- Unlocked in " + nameOfCurrentThread + " (" + _stackTraces.count() + " remaining)");

172

}

173

174

public void goodbye() {

175

if (_stackTraces.count() != 0) {

176

NSLog.err.appendln("!!! editing context being disposed with " + _stackTraces.count() + " locks.");

177

NSLog.err.appendln("!!! Most recently locked by: \n"

178

+ _stackTraces.lastObject());

}

}

public void dispose() {

goodbye();

super.dispose();

}

protected void finalize() throws Throwable {

try {

goodbye();

} finally {

super.finalize();

}

}

private String _trace() {

196

StringWriter stringWriter = new StringWriter();

197

PrintWriter printWriter = new PrintWriter(stringWriter);

198

(new Throwable()).printStackTrace(printWriter);

199

return stringWriter.toString();

}

}

Now you'll have to get the subclass substituted whenever an EOEditingContext is created. Too bad there's no generalized EOEditingContext factory method in WOF, but this will cover default editing contexts:

public class Session extends WOSession {

210

public Session() {

211

super();

212

setDefaultEditingContext( new LockErrorScreamerEditingContext() );

213