Java 8 - Fatal exception - com/webobjects/foundation/NSTimeZone$__NSTZPeriod
Hi List, I updated my dev's computer from java 7 to java 8. When I try to launch my app, I get a fatal error (WARN NSLog - A fatal exception occurred: com/webobjects/foundation/NSTimeZone$__NSTZPeriod) on foundation framework and the app shutdown. Have I miss a parameter in properties for patching this error ? Thanks for Help Envoyé depuis iCloud ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
WOSession serialisation redux
Hello, This issue comes up every few years. (I just re-read an epic thread on this and other issues from 2010.) Here it is again. I have a really simple question: is _anyone_ successfully serialising WOSession objects (using _any_ method, and preferably _not_ native Java serialisation) with a view to using a WOSessionStore that’s not based in local memory in non-trivial, non-demo apps? I’ve had a look at Ramsey’s ERPersistentSessionStorage.framework, and my intention was to create something similar backed by memcached. I got it working to the proof-of-concept level on a trivial app, but using native Java serialisation seems brittle. (By which I mean it falls over pretty fast when you throw a serialisation-based approach into a substantial application.) Is this problem solved, unsolved, or unsolvable? Is _anyone_ using non-local session storage of _any_ kind? -- Paul Hoadley http://logicsquad.net/ ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: WOSession serialisation redux
On May 19, 2015, at 4:51 PM, Paul Hoadley pa...@logicsquad.net wrote: Hi Ramsey, On 20 May 2015, at 1:53 am, Ramsey Gurley rgur...@smarthealth.com wrote: On May 19, 2015, at 4:03 AM, Paul Hoadley pa...@logicsquad.net wrote: I’ve had a look at Ramsey’s ERPersistentSessionStorage.framework, and my intention was to create something similar backed by memcached. I got it working to the proof-of-concept level on a trivial app, but using native Java serialisation seems brittle. (By which I mean it falls over pretty fast when you throw a serialisation-based approach into a substantial application.) I’m curious about the falls over pretty fast part. What sort of problems do you have? Serialization failures. (To be clear, I’m talking about testing with my own memcached-based approach, but it’s really only some very minor changes to your work to use memcached instead of the database as the back-end.) Initially it was my own classes, which I could fix, but then I started hitting weirdness like this: Caused by: java.io.NotSerializableException: java.lang.reflect.Field It’s not obvious to me where that’s coming from, or how to fix it. Findbugs is really good at finding these. Install the plugin, run it on your code (and wonder code that you use), and look for the serialization issues it produces. It can be a bit tricky to find serialization errors if these non-serializable objects are stuffed inside a serializable object (NSArrayField). In any case, you can usually put an uncaught exception breakpoint in eclipse to stop the program on these exceptions so you can pick through the stack to find the culprit. In my testing and WOWODC demo, I had it working well enough to run all page configurations of R2D2W and ERModern apps. I had also formed the impression (perhaps erroneously!) that you had found serialization issues deeper inside the WebObjects frameworks that were going to be difficult or impossible to fix. The only major remaining issue I had was ECs serialization with related EOs. I had it mostly fixed in EOCustomObject in ERPersistentSessionStorage, but it would still pop up occasionally. A little jadclipse could go a long way here. Oh, and the session reaper puts something like a 2 week uptime limit on your apps if you used sessions that never expire. Just schedule restarts once a week or something for instances should work around that. I didn’t see any reason to replace the original wosessionstore super class just to fix that. Basically I wrote that framework to prove to myself that a component action/D2W app could be used as a “front end” app at scale and do a better job of it to boot. I succeeded in convincing myself that it was possible and left it there :-) What would it take to get you back into this? Let’s start with a show of hands: is anyone else interested in developing a robust solution to this problem? I’ve kinda moved on to other interests, but there’s little to stop you guys from doing it. I felt like I had it about 95% there. ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: WOSession serialisation redux
Hi Ramsey, On 20 May 2015, at 1:53 am, Ramsey Gurley rgur...@smarthealth.com wrote: On May 19, 2015, at 4:03 AM, Paul Hoadley pa...@logicsquad.net wrote: I’ve had a look at Ramsey’s ERPersistentSessionStorage.framework, and my intention was to create something similar backed by memcached. I got it working to the proof-of-concept level on a trivial app, but using native Java serialisation seems brittle. (By which I mean it falls over pretty fast when you throw a serialisation-based approach into a substantial application.) I’m curious about the falls over pretty fast part. What sort of problems do you have? Serialization failures. (To be clear, I’m talking about testing with my own memcached-based approach, but it’s really only some very minor changes to your work to use memcached instead of the database as the back-end.) Initially it was my own classes, which I could fix, but then I started hitting weirdness like this: Caused by: java.io.NotSerializableException: java.lang.reflect.Field It’s not obvious to me where that’s coming from, or how to fix it. I had also formed the impression (perhaps erroneously!) that you had found serialization issues deeper inside the WebObjects frameworks that were going to be difficult or impossible to fix. I had a few unresolved bugs that could have probably been fixed by rewriting EOEditingContext’s serialization routine, but I never bothered. That sounds a lot more promising. I was under the impression you had abandoned the idea because the problem was unsolvable. It became obvious to me that a) nobody was interested in fixing serialization in their legacy classes, I’m interested! and b) everyone was too proud of their one-off direct action workarounds to this particular problem to look at a new solution that works for everything. I am really interested in being able to decouple session persistence from the application server to allow for automated horizontal scaling of component action-based apps. Basically I wrote that framework to prove to myself that a component action/D2W app could be used as a “front end” app at scale and do a better job of it to boot. I succeeded in convincing myself that it was possible and left it there :-) What would it take to get you back into this? Let’s start with a show of hands: is anyone else interested in developing a robust solution to this problem? -- Paul Hoadley http://logicsquad.net/ ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: WOSession serialisation redux
On Wed, May 20, 2015, at 09:51 AM, Paul Hoadley wrote: Hi Ramsey, On 20 May 2015, at 1:53 am, Ramsey Gurley rgur...@smarthealth.com wrote: On May 19, 2015, at 4:03 AM, Paul Hoadley pa...@logicsquad.net wrote: I’ve had a look at Ramsey’s ERPersistentSessionStorage.framework, and my intention was to create something similar backed by memcached. I got it working to the proof-of-concept level on a trivial app, but using native Java serialisation seems brittle. (By which I mean it falls over pretty fast when you throw a serialisation-based approach into a substantial application.) I’m curious about the falls over pretty fast part. What sort of problems do you have? Serialization failures. (To be clear, I’m talking about testing with my own memcached-based approach, but it’s really only some very minor changes to your work to use memcached instead of the database as the back-end.) Initially it was my own classes, which I could fix, but then I started hitting weirdness like this: Caused by: java.io.NotSerializableException: java.lang.reflect.Field It’s not obvious to me where that’s coming from, or how to fix it. I had also formed the impression (perhaps erroneously!) that you had found serialization issues deeper inside the WebObjects frameworks that were going to be difficult or impossible to fix. I had a few unresolved bugs that could have probably been fixed by rewriting EOEditingContext’s serialization routine, but I never bothered. That sounds a lot more promising. I was under the impression you had abandoned the idea because the problem was unsolvable. It became obvious to me that a) nobody was interested in fixing serialization in their legacy classes, I’m interested! and b) everyone was too proud of their one-off direct action workarounds to this particular problem to look at a new solution that works for everything. I am really interested in being able to decouple session persistence from the application server to allow for automated horizontal scaling of component action-based apps. Basically I wrote that framework to prove to myself that a component action/D2W app could be used as a “front end” app at scale and do a better job of it to boot. I succeeded in convincing myself that it was possible and left it there :-) What would it take to get you back into this? Let’s start with a show of hands: is anyone else interested in developing a robust solution to this problem? -- Paul Hoadley http://logicsquad.net/ I'm most certainly interested :) As you know, I dabbled with the framework for a project but came across some serialization problems deep in the frameworks. I am really interested in the approach you mention above, Ramsey, with the EC serialization routine. My intention was to use ElastiCache. -- Matt http://logicsquad.net ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Java 8 - Fatal exception - com/webobjects/foundation/NSTimeZone$__NSTZPeriod - [SOLVED]
Hi List,
To patch the exception I create a new NSTimeZone class in a package
com.webobjects.foundation in my app sources and I patched the java 8 error by
forcing the classLoader to load __NSTZPeriod earlier.
a method which I call :
patchForJre18() {
__NSTZPeriod pourForcerLeClassLoader = new __NSTZPeriod();
}
And then in the new NSTimeZone class put the patch in :
static {
try {
patchForjre18();
...
}
...
}
that's all.
I hope it will help someone else.
Thanks
Envoyé depuis iCloud
Le 19 mai 2015 à 09:44, Raymond NANEON rnan...@me.com a écrit :
Hi List,
I updated my dev's computer from java 7 to java 8.
When I try to launch my app, I get a fatal error (WARN NSLog - A fatal
exception occurred: com/webobjects/foundation/NSTimeZone$__NSTZPeriod) on
foundation framework and the app shutdown.
Have I miss a parameter in properties for patching this error ?
Thanks for Help
Envoyé depuis iCloud
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/rnaneon%40me.com
This email sent to rnan...@me.com
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: WOSession serialisation redux
On May 19, 2015, at 4:03 AM, Paul Hoadley pa...@logicsquad.net wrote: I’ve had a look at Ramsey’s ERPersistentSessionStorage.framework, and my intention was to create something similar backed by memcached. I got it working to the proof-of-concept level on a trivial app, but using native Java serialisation seems brittle. (By which I mean it falls over pretty fast when you throw a serialisation-based approach into a substantial application.) I’m curious about the falls over pretty fast part. What sort of problems do you have? I had a few unresolved bugs that could have probably been fixed by rewriting EOEditingContext’s serialization routine, but I never bothered. It became obvious to me that a) nobody was interested in fixing serialization in their legacy classes, and b) everyone was too proud of their one-off direct action workarounds to this particular problem to look at a new solution that works for everything. Basically I wrote that framework to prove to myself that a component action/D2W app could be used as a “front end” app at scale and do a better job of it to boot. I succeeded in convincing myself that it was possible and left it there :-) ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Back with weird problems: PK generation keeps generating same PK... up to a moment.
On 2015-05-17, 3:12 AM, ocs.cz wrote:
Samuel,
On 14 5 2015, at 2:12 am, Samuel Pelletier
sam...@samkar.commailto:sam...@samkar.com wrote:
I think your problem is with the locking. Optimistic locking does not lock
anything it check on commit if things have changed.
Right; but does it potentially mess up PK generation? I thought it should not,
but of course, as so often, I can be wrong.
I think that switching to pessimistic locking will help this situation
Originally, we have used pessimistic locking, but we have found it gets a bit
slow. Correct me please if I am overlooking something of importance, but far as
I know (and by my testing) it seems when pessimistic, even _reads_ are locked
out and wait till the first transaction is committed.
We sort of need that anybody can read, and that any locking and induced delays
happens only for those who edit, leaving readers unaffected.
for a multiple instance setup
Actually, the problem did happen in single-instance, but with concurrent
requests on.
the sequence will be locked for the remaining transaction time. This will
prevent other instance to obtain primary keys during the remaining of the
transaction but will keep your primary key generator safe.
Hmmm I wonder.
What if I generated all the PKs myself programmatically, using something like a
milli- or even microsecond timestamp?
EOF has a 40 byte UUID PK type that, in theory, would avoid this problem. But
you would have to convert all of the existing keys.
That should make clashes possible, but extremely improbable. I might even
dedicate some bits to encode the thread number into the PK; in that case the
clashes should be nearly impossible.
For the extremely rare cases when they would happen, I suppose it should be
somewhat hairy: I would have to change the affected PK to the current
timestamp, and go through all the relationships to change the appropriate
FKs... ick, that could get ugly, but I suppose it should happen _extremely_
rarely?
This current problem was extremely rare too, no? :-)
(I know EOF can do better itself, but not with INTEGER PKs.)
That said, it might be better to let EOF do its best with optimistic locking,
and if the PK clash -- again very improbable, but possible -- happens, send to
the DB SET UNIQUE FOR offending table(its PK), and retry?
That would work too, but I am surprised that this is needed. I really am not
grasping what could have happened here.
Chuck
Thanks a big lot,
OC
Le 2015-05-13 à 13:05, OC o...@ocs.czmailto:o...@ocs.cz a écrit :
Samuel,
On 12. 5. 2015, at 23:49, Samuel Pelletier
sam...@samkar.commailto:sam...@samkar.com wrote:
Sequence generation for concurrent access may be tricky to do right, especially
if the system is tuned for performance. There is a confrontation between the
sequence integrity and the concurrent access. It is easy to use a sequence
table wrong...
Definitely, and I am far from sure I am doing it right. Nevertheless it seems
to be reasonably well tested.
Also, I do not use a separate sequence table; my approach is much simpler:
there is a sequential attribute guarded by a UNIQUE constraint, and the saving
code simply detects that this constraint failed, and if so, increments the
value of the attribute and tries again.
That is far from efficient in case there is a lot of clashes, but they happen
to be reasonably rare; and it should be pretty fail-proof, or am I overlooking
something of importance?
OC, which database are you using
FrontBase. Let me see the logs... at the server, there is 5.2.1g, a pretty old
one.
Other sw versions: Groovy 2.3.8 / WebObjects 5.4.3 / ERExt's 6.1.3-SNAPSHOT /
Java 1.6.0_65 / Mac OS X 10.6.8.
with which connection settings for isolation and locking
Read-committed, optimistic.
and how your primary key are generated ?
Standard untouched EOF approach. All my PKs are INTEGERs.
Thanks a lot,
OC
Le 2015-05-12 à 17:09, Chuck Hill
ch...@gevityinc.commailto:ch...@gevityinc.com a écrit :
You really do come up with the absolute best problems! :-)
www.youtube.com/watch?v=otCpCn0l4Wo
My guess is that somehow the database failed to record the update to the
sequence number. Every time you ran it after that, it generated the used one
and then failed. When you added logging, something that you added caused two to
get generated with the first not used. Then everything worked again.
Except... sequences should be generated outside of the ACID transition so I
can't see how this could happen once, let alone multiple times.
Chuck
On 2015-05-12, 1:56 PM, OC wrote:
Hello there,
my application, among others, generates and stores audit records. The
appropriate code is comparatively straightforward; it boils down to something
like
===
... ec might contain unsaved objects at this moment ...
DBAudit audit=new DBAudit()
ec.insertObject(audit)
audit.takeValuesFromDictionary(... couple of plain attributes ...)
for (;;) { // see below the specific situation which causes a retry
try {
Re: Back with weird problems: PK generation keeps generating same PK... up to a moment.
On 2015-05-17, 3:19 AM, ocs.cz wrote: Chuck, On 14 5 2015, at 2:22 am, Chuck Hill ch...@gevityinc.commailto:ch...@gevityinc.com wrote: FrontBase will return the sequence number if the transaction is rolled back, but I am pretty sure that EOF does a commit immediately after selecting for a PK. It is possible that somehow the commit after the PK select failed and the exception got eaten, I suppose. That seems a bit far fetched. Hmmm here I might possibly see a way to prevent the problem in future: correct me please if I am wrong, but I understand permanentGlobalID causes this generation (and commit), right? IIRC, the generation and commit are from EOF. permanentGlobalID calls into that code to get the ID. Well then, what if I, at the moment any EO gets inserted into an EC, immediatelly called permanentGlobalID for it? The original problem was caused, as best I can call, by FrontBase vending the same sequence number twice. Doing what you describe won't change or avoid that underlying problem. It will just change when it happens. Chuck Unless I am overlooking something, it should get, commit and assign a safe PK for the EO. Later, when the EO gets saved, no PK clash would be possible. About the only drawback I can see is that when generating lots of new EOs, there would be many unnecessary roundtrips to the DB and it would be sloow. But normally I create at worst tens (normally just a couple) of EOs inside a r/r loop, and batch imports etc. need to be optimised separately anyway. Might this be a solution? Or am I overlooking something of importance, as so often? Thanks a lot, OC ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Ajax Servlet Deployment
Hi,
I am attempting to deploy a web page where the page uses an
AjaxFlexibleFileUpload component. This works in the development setup. However,
once the page with the AjaxFlexibleFileUpload loads on the server the two XHRs
that run come back with 200 responses but they are completely empty of content.
This results in no file dialog appearing when a user attempts to select an
image for upload.
The errors that show in the browser JS console are JSONRpcClientException:
error parsing result”, ReferenceError: Can't find variable: jsonrpc_0 and
ReferenceError: Can't find variable: jsonrpc_1.
My local development setup is a (reverse) proxy through NGINX. The deployment
is to a AWS Elastic Beanstalk, in Tomcat 7, Java 7 which uses Apache as a
reverse proxy.
I’ll admit I know very little about WebObjects and Ajax. It is not clear to me
that I have all the correct steps for using Ajax components. One thing I did
was to override pageWithName in the Application class.
@Override
public WOComponent pageWithName(String name, WOContext context)
{
log.error(application pageWithName + name + + context);
WOComponent page = super.pageWithName(name, context);
log.error(got page + page);
return page;
}
I noticed that when run locally there is nothing in the logs for the XHR
requests because they load fine. However, when deployed to a Beanstalk instance
I get the following.
ERROR 20:32:35 (com.adnero.finance.web.Application:?) -application
pageWithName null er.extensions.appserver.ERXWOServletContext contextID=0
requestSenderID=0.17.1.1.1.0.1 elementID=null sessionID=GpMB9KKAiBu1Rdv4MqVNu0
request=er.extensions.appserver.ERXRequest
(er.extensions.appserver.ERXRequest httpVersion=HTTP/1.0
headers={accept=[*/*], accept-encoding=[gzip, deflate],
accept-language=[en-us], connection=[Keep-Alive], content-length=[50],
content-type=[text/plain],
cookie=[JSESSIONID=727EEEFD467421EFD51BB2A65A0707BF], dnt=[1],
host=[replaced.host.url], origin=[http://replaced.host.url],
referer=[http://replaced.host.url/WebObjects/AdneroWeb.woa/wo/0.0.0.17.1],
remote_addr=[104.200.104.189], user-agent=[Mozilla/5.0 (Macintosh; Intel Mac OS
X 10_10_3) AppleWebKit/600.6.3 (KHTML, like Gecko) Version/8.0.6
Safari/600.6.3], x-forwarded-host=[replaced.host.url],
x-forwarded-server=[ip-172-31-26-217.ec2.internal],
x-requested-with=[XMLHttpRequest], x-webobjects-adaptor-version=[5.2],
x-webobjects-servlet-server-name=[replaced.host.url],
x-webobjects-servlet-server-port=[80]} content-length=50 cookies=null
userInfo={ServletConfig=org.apache.catalina.core.StandardWrapperFacade@7f127e0,
ServletContext=org.apache.catalina.core.ApplicationContextFacade@6970e732,
HttpServletRequest=org.apache.catalina.connector.RequestFacade@2b18fb03,
HttpServletResponse=org.apache.catalina.connector.ResponseFacade@7507980f}
storePageInBacktrackCache=true ) method=POST
uri=/WebObjects/AdneroWeb.woa/ajax/0.0.17.1.1.1.0.1
defaultFormValueEncoding=UTF-8 formValueEncodingDetectionEnabled=NO
formValueEncoding=UTF-8 formValues={WOIsmapCoords =
({id:1,method:system.listMethods,params:[]}); } response=null
pageElement=null pageComponent=null currentComponent=null
url=/WebObjects/AdneroWeb.woa urlApplicationNumber=-1 distributionEnabled=false
pageChanged=false pageReplaced=false
ERROR 20:32:35 (com.adnero.finance.web.Application:?) -got page
com.adnero.finance.web.pages.Main name: com.adnero.finance.web.pages.Main
subcomponents: null
I am guessing that this differences means that the ajax requests are not being
handled by the Ajax Handler but are getting caught by the default handler or
that they are falling back to pageWithName, (which then falls back to
Main.class) when they should not be?
My apache config for the proxy looks like this:
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/WebObjects/Frameworks/ [NC]
RewriteRule ^/WebObjects/Frameworks/(.+)$ /WebServerResources/Frameworks/$1 [PT]
RewriteCond %{REQUEST_URI} ^/WebObjects/Contents/ [NC]
RewriteRule ^/WebObjects/Contents/(.+)$ /WebServerResources/Contents/$1 [PT]
RewriteCond %{REQUEST_URI}
^/WebObjects/AdneroWeb.woa/Contents/WebServerResources/ [NC]
RewriteRule ^/WebObjects/AdneroWeb.woa/Contents/WebServerResources/(.+)$
/WebServerResources/Contents/WebServerResources/$1 [PT]
RewriteCond %{REQUEST_URI} ^/ishealthy$ [NC]
RewriteRule ^/ishealthy$ /WebObjects/AdneroWeb.woa/ra/Healthcheck/ishealthy [PT]
Proxy *
Order deny,allow
Allow from all
/Proxy
ProxyPass / http://localhost:8080/ retry=0
ProxyPassReverse / http://localhost:8080/
ProxyPreserveHost on
LogFormat %h (%{X-Forwarded-For}i) %l %u %t \%r\ %s %b \%{Referer}i\
\%{User-Agent}i\
ErrorLog /var/log/httpd/elasticbeanstalk-error_log
TransferLog /var/log/httpd/elasticbeanstalk-access_log
I am completely lost as to what to try next. Any help in identifying why the
Ajax requests are not being handled properly would be appreciated.
___
Re: Back with weird problems: PK generation keeps generating same PK... up to a moment.
Chuck, On 19 5 2015, at 11:13 pm, Chuck Hill ch...@gevityinc.com wrote: Well then, what if I, at the moment any EO gets inserted into an EC, immediatelly called permanentGlobalID for it? The original problem was caused, as best I can call, by FrontBase vending the same sequence number twice. Which itself was (probably, far as I can say) caused by an exception during a transaction (namely, an exception triggered by an UNIQUE constraint) and rollback. As always, I might be overlooking something of importance, but it seemed me that simple permanentGlobalID-triggered get-me-next-PK roundtrip would never ever cause an exception. The UNIQUE thing of course might cause an exception essentially any time -- *but*, when this happens, the PK will be already assigned, committed and safe. Thus it seemed to me... Doing what you describe won’t change or avoid that underlying problem. It will just change when it happens. ... it actually would avoid the problem -- by separating “a transaction during which a PK gets assigned” from “a transaction which might be aborted by the UNIQUE exception“. But of course I might be missing some important point? Thanks a big lot for all the help, OC ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Back with weird problems: PK generation keeps generating same PK... up to a moment.
Turn on SQL logging and see what happens. I don't recall if the Pks are generated in their own transaction or as part of the saveChanges() transaction. If they are generated and committed in their own transaction (which is my guess), then your proposal won't help. Chuck On 2015-05-19, 2:24 PM, ocs.cz wrote: Chuck, On 19 5 2015, at 11:13 pm, Chuck Hill ch...@gevityinc.commailto:ch...@gevityinc.com wrote: Well then, what if I, at the moment any EO gets inserted into an EC, immediatelly called permanentGlobalID for it? The original problem was caused, as best I can call, by FrontBase vending the same sequence number twice. Which itself was (probably, far as I can say) caused by an exception during a transaction (namely, an exception triggered by an UNIQUE constraint) and rollback. As always, I might be overlooking something of importance, but it seemed me that simple permanentGlobalID-triggered get-me-next-PK roundtrip would never ever cause an exception. The UNIQUE thing of course might cause an exception essentially any time -- *but*, when this happens, the PK will be already assigned, committed and safe. Thus it seemed to me... Doing what you describe won't change or avoid that underlying problem. It will just change when it happens. ... it actually would avoid the problem -- by separating a transaction during which a PK gets assigned from a transaction which might be aborted by the UNIQUE exception. But of course I might be missing some important point? Thanks a big lot for all the help, OC ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Open D2W pull requests seeking help
Hi all, we currently have a couple of open pull requests for Wonder regarding D2W topics. In the course of getting pull requests merged or closed without endless waiting we need D2W skilled people who could take a look at those pull requests and leave some comments about usefulness/corrections/whatever. Here are the specific pull requests: https://github.com/wocommunity/wonder/pull/496 https://github.com/wocommunity/wonder/pull/500 https://github.com/wocommunity/wonder/pull/629 Further there are some open issues that could take a look (did you know that submitting a pull request is rally easy? ;): https://github.com/wocommunity/wonder/issues/89 https://github.com/wocommunity/wonder/issues/93 https://github.com/wocommunity/wonder/issues/97 Thanks helping the community! jw signature.asc Description: Message signed with OpenPGP using GPGMail ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
