Transcation not active nearly always points at earlier errors which caused the
transaction state to become invalid. Here I would guess it is related to the
PropertyNotFoundException - this would normally have a root cause.
View the original post :
http://www.jboss.com/index.html?module=bb&op=v
Sorry, title should have been: "Random Transaction not active errors".
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102660#4102660
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102660
__
I have submitted a patch to the JIRA that uses a session scoped
conversationIdGenerator. This is my first attempt at submitting a patch, so all
comments/criticisms are welcome.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4095450#4095450
Reply to the post :
I'm +1 on providing a UUID/GUID strategy, -1 on changing the default strategy.
Anyway, I'm not convinced this is super high priority.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4095249#4095249
Reply to the post :
http://www.jboss.com/index.html?module=bb
I've hit the problem many times before. Even if it were "quite rare", it's
still worth providing another strategy for users who are concerned about it.
Although I think we should change the default behavior, I am not inclined to do
that because of the increased URL complexity. People are alre
The feature request is for the ability to overide the cid generator with a seam
component. This would make it very easy to use incremental cid's in development
and UID's in production to eliminate any chance of cid collision's, while still
making it easy to debug.
View the original post :
http
1) No, they will get a new Session ID and the cid=2 is not used (assuming that
they bookmarked a non-conversational page - which is the normal case). We are
already discussing if appending the ID of a temporary conversation makes sense
at all.
2) User error, agreed this might be useful for that
anonymous wrote :
| Ahem, conversation IDs are _already_ globally unique because by definition,
they are combined with the unique session ID. There is no way you can "step
back into conversation 5" from a bookmark with a reasonably short session
timeout.
|
I have two use cases where this
Ahem, conversation IDs are _already_ globally unique because by definition,
they are combined with the unique session ID. There is no way you can "step
back into conversation 5" from a bookmark with a reasonably short session
timeout.
View the original post :
http://www.jboss.com/index.html?m
http://jira.jboss.com/jira/browse/JBSEAM-2105
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4095068#4095068
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4095068
___
jboss
Sounds like a good idea to me :) I'm concerned that trying to hook into current
methods like the OP described would break something.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4095046#4095046
Reply to the post :
http://www.jboss.com/index.html?module=bb&o
+1 for a UUID. Random does not guarantee that the id will be unique at the time
it is generated so there is a chance for a collision. A UUID on the other hand
alleviates that concern.
Currently for monitoring purposes from an interceptor I use a UUID that I
outject from conversation startup so
I've always been worried about bookmarked URLs. If you bookmark a URL with,
for example, id=5, it's not very farfetched to think that at some point in the
future when you use the link that you will have an existing conversation with
an id 5 that you'd be stepping into. If conversation IDs were
Why do you want to do this?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4095014#4095014
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4095014
___
jboss-user mailing list
jbo
14 matches
Mail list logo
