This is a usage problem. PojoCache creates internal nodes in /__JBossInternal__ which aren't cleared since PojoCache is bypassed for the bulk delete operation. So basically any object that has attach() called on it, can only be removed via the PojoCache detach method.
Also, the structure __JBossInternal__ is not considered public so you should not attempt to modify it yourself.
So the only way to do a bulk delete operation at the moment, is to iterate over all of the ids and call detach() on each one. Feel free to create a feature request if this is not sufficient.
-Jason
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4024796#4024796
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4024796
Hello,
I am developing an EJB application in a JBoss application server. Several clients (Swing clients) have to connect to this application to load, modify insert data in a database (using entity and session beans).
But I have a problem to solve. When two or more clients are accessing to the same row, one of them can modify this row and, then, the others are working with an out-of-date data of the row (dirty read).
¿It's possible to notify to all connected clients that some row (or rows) have changed? ¿And to update the data of these clients from server?
Thank you very much
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4024794#4024794
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4024794
I just now read this thread and mailed Gavin. If I don't hear from him I'll crash it anyway, as I wouldn't miss this :-)
A local Seam user group sounds great. My personal effort right now is to integrate the Google Web Toolkit and Seam. My rationale is here:
http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/90...
The technical goal is to make it straightforward to implement GWT modules as JSF widgets, making RPC calls to interfaces exposed by Seam components.
I've gotten as far as getting a GWT patch 99% accepted to the GWT 1.4 release:
http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thr...
And based on that I have another patch ready for the g4jsf project, as soon as the GWT patch is committed (the ajax4jsf guys have given me the thumbs-up):
https://ajax4jsf.dev.java.net/servlets/ReadMsg?list=users&msgNo=2719
All of this is leading up to making an example of a GWT module integrated into a Seam application. I'm thinking of converting the booking example, a la Todd Smart's ajax4jsf integration, so that the confirmation UI is implemented as a GWT module.
Now, there are all kinds of interesting ramifications of this. The GWT direction is to make rich clients -- dare I say, conversational clients -- much easier to build. The Seam direction is to make richly conversational server-based applications much easier to build. So there's some sizable overlap. I'm hoping to ask around tonight about how the Seam guys see the two technologies and their tradeoffs.
See you all tonight :-)
Cheers!
Rob
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4024793#4024793
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4024793
Actually I?ve worked around it.
I have implemented it as a Java Bean with an EntityManager being injected.
@In EntityManager entityManager
I changed it to a Stateless Session Bean and switched the EntityManager injection to
@PersistenceContext EntityManager entityManager;
Now it?s working.
Maybe the entityManager injected wasn't commited because it was out of an HTTP request.
So my conclusion is that to use an EntityManager in the event preDestroyContext.SESSION, we HAVE to implement it as a Session Bean and use a @PersistenceContext annotation to inject it. Right?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4024784#4024784
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4024784
it seems that EntityManager.persist( o ) does not put object o into EJB3EntityTreeCache. at least it does not appear if i go to the jmx console and invoke EJB3EntityTreeCache.printDetails(). however, after the first call to EntityManager.find() that returns the newly persisted objec o, that object does apper when i invoke EJB3EntityTreeCache.printDetails(). some my questions are:
is that the expected behavior?
does that imply that i make a trip to the db that i don't really need?
thanks.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4024780#4024780
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4024780