Re: [Resin-interest] Resin cluster failure with a singlenoderunning out of heap space
nope, no thread dump unfortunately. the whole cluster had been restarted by the IT department of my client before I came in to help figure out what had happened. I will tell them to get a thread dump if it happens again. I don't think the JVM itself was frozen. but I am not sure. in the meantime, I think we will try increasing the heap size and the memory-free-min value. ..mike.. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Ferguson Sent: Monday, March 10, 2008 4:42 PM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] Resin cluster failure with a singlenoderunning out of heap space On Mar 10, 2008, at 3:57 PM, Mike Wynholds wrote: > Hmmm... we do have a setting of 1MB (Scott asked > about > that just before this email). So then how would Resin still get an > OOM > error? Is there a thread in the server that watches the heap space? > Because we do a lot of in-JVM image manipulation, which takes up a LOT > of memory and quite quickly. So if it is a timing issue, it's > possible > that the heap-watcher doesn't have a chance to act quickly enough. It's the main thread and checked every 10 seconds. So it's possible that using a lot of memory could run by it. Still, that thread should detect the problem after 10 seconds and force a restart. Although, memory checking isn't exact. It's even possible the original failure freed up memory between checks, but that's not likely. Did you happen to get a thread dump or was the JVM itself frozen? JVM freezes are hard to deal with. -- Scott > > > ..mike.. > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Sam > Sent: Monday, March 10, 2008 3:38 PM > To: General Discussion for the Resin application server > Subject: Re: [Resin-interest] Resin cluster failure with a single > noderunning out of heap space > >> We are currently looking at our watchdog process config to see why it >> did not auto-restart Resin. I think we didn't give enough memory > buffer >> for the watchdog to detect a needed restart, and our app lost >> responsiveness before the watchdog could restart it. But that's just > a >> theory. > > The memory low detection happens within the server itself. If the > server itself detects that the memory is about to be exhausted, it > exits. The watchdog then notices that the server did not exit > cleanly, > and starts a new server to replace it. > > -- Sam > > > > ___ > resin-interest mailing list > resin-interest@caucho.com > http://maillist.caucho.com/mailman/listinfo/resin-interest > > > ___ > resin-interest mailing list > resin-interest@caucho.com > http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin cluster failure with a single noderunning out of heap space
On Mar 10, 2008, at 3:57 PM, Mike Wynholds wrote: > Hmmm... we do have a setting of 1MB (Scott asked > about > that just before this email). So then how would Resin still get an > OOM > error? Is there a thread in the server that watches the heap space? > Because we do a lot of in-JVM image manipulation, which takes up a LOT > of memory and quite quickly. So if it is a timing issue, it's > possible > that the heap-watcher doesn't have a chance to act quickly enough. It's the main thread and checked every 10 seconds. So it's possible that using a lot of memory could run by it. Still, that thread should detect the problem after 10 seconds and force a restart. Although, memory checking isn't exact. It's even possible the original failure freed up memory between checks, but that's not likely. Did you happen to get a thread dump or was the JVM itself frozen? JVM freezes are hard to deal with. -- Scott > > > ..mike.. > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Sam > Sent: Monday, March 10, 2008 3:38 PM > To: General Discussion for the Resin application server > Subject: Re: [Resin-interest] Resin cluster failure with a single > noderunning out of heap space > >> We are currently looking at our watchdog process config to see why it >> did not auto-restart Resin. I think we didn't give enough memory > buffer >> for the watchdog to detect a needed restart, and our app lost >> responsiveness before the watchdog could restart it. But that's just > a >> theory. > > The memory low detection happens within the server itself. If the > server itself detects that the memory is about to be exhausted, it > exits. The watchdog then notices that the server did not exit > cleanly, > and starts a new server to replace it. > > -- Sam > > > > ___ > resin-interest mailing list > resin-interest@caucho.com > http://maillist.caucho.com/mailman/listinfo/resin-interest > > > ___ > resin-interest mailing list > resin-interest@caucho.com > http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin cluster failure with a single noderunning out of heap space
Hmmm... we do have a setting of 1MB (Scott asked about that just before this email). So then how would Resin still get an OOM error? Is there a thread in the server that watches the heap space? Because we do a lot of in-JVM image manipulation, which takes up a LOT of memory and quite quickly. So if it is a timing issue, it's possible that the heap-watcher doesn't have a chance to act quickly enough. ..mike.. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sam Sent: Monday, March 10, 2008 3:38 PM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] Resin cluster failure with a single noderunning out of heap space > We are currently looking at our watchdog process config to see why it > did not auto-restart Resin. I think we didn't give enough memory buffer > for the watchdog to detect a needed restart, and our app lost > responsiveness before the watchdog could restart it. But that's just a > theory. The memory low detection happens within the server itself. If the server itself detects that the memory is about to be exhausted, it exits. The watchdog then notices that the server did not exit cleanly, and starts a new server to replace it. -- Sam ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin cluster failure with a single node running out of heap space
> We are currently looking at our watchdog process config to see why it > did not auto-restart Resin. I think we didn't give enough memory buffer > for the watchdog to detect a needed restart, and our app lost > responsiveness before the watchdog could restart it. But that's just a > theory. The memory low detection happens within the server itself. If the server itself detects that the memory is about to be exhausted, it exits. The watchdog then notices that the server did not exit cleanly, and starts a new server to replace it. -- Sam ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Managing separate watchdog processes in 3.1.5
http://www.caucho.com/resin/doc/resin-watchdog.xtp I also want to run multiple independent instances on the same machine. Scott and company, I think it will be useful to include an example of that in the resin 3.1 documentation for the watchdog process. This is a big change from Resin 3.0 which took me a while to figure out. Bill On Mon, Mar 10, 2008 at 5:19 PM, Eric Kreiser <[EMAIL PROTECTED]> wrote: > Is there a way to specify what IP the watchdog-port will bind to? > > I want to be able to have a number of sites/instances of resin running on > a machine > I want all of them to run independent of each other > > so to keep them independent, I need to specify a watchdog-port... but if I > do... it binds to the main ip of the machine... so in my scenario, I would > need to assign each resin instance a unique port number. > > Is there a better way for me to handle this? > > Thanks > Eric Kreiser > > > > ___ > resin-interest mailing list > resin-interest@caucho.com > http://maillist.caucho.com/mailman/listinfo/resin-interest > > ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin cluster failure with a single node running out of heap space
On Mar 10, 2008, at 3:05 PM, Mike Wynholds wrote: Scott and others- My client has a five-node Resin Pro cluster, each running version 3.1.2. Today one of the nodes experienced an OutOfMemoryException which did not bring Resin down but seemed to have put it in a completely unresponsive state. Do you have the set? Resin should restart itself before it gets to OOM. The problem with OOM is that errors and behavior start becoming undefined. Basically, it's not possible to really handle OOM other than restarting the system. The makes sure Resin restarts before that situation occurs. -- Scott With 10 minutes or so of that happening, the other four servers stop responding as well. Looking at their logs shows that they are continuously getting socket timeouts while trying to communicate with the first server for session clustering. (Stack trace below). To be fair, this is not the only exception being thrown. We also see our distributed EhCache system unsuccessfully trying to replicate itself. And we *also* see the occasional Hessian exception happening (also below). Ultimately the server just gets so bogged down, it seems, that it needs to be restarted. So my question is this: Assuming a Resin node runs out of memory, is there a way for other Resin nodes to detect that and take the same action as if the node was actually down? I’m not sure this is really a bug, but it is probably a good super-edge-case scenario worth thinking about. We are currently looking at our watchdog process config to see why it did not auto-restart Resin. I think we didn’t give enough memory buffer for the watchdog to detect a needed restart, and our app lost responsiveness before the watchdog could restart it. But that’s just a theory. I am interested in feedback from Scott and other Caucho developers about this issue, as well as other Resin users who may have experienced issues like this before and have any thoughts or suggestions on the matter. Thanks. ..mike.. --- Socket Timeout stack trace (partial) --- [14:47:10.389] java.net.SocketTimeoutException: Read timed out [14:47:10.389] at java.net.SocketInputStream.socketRead0(Native Method) [14:47:10.389] at java.net.SocketInputStream.read(SocketInputStream.java:129) [14:47:10.389] at com.caucho.vfs.TcpStream.read(TcpStream.java:163) [14:47:10.389] at com.caucho.vfs.ReadStream.readBuffer(ReadStream.java:1001) [14:47:10.389] at com.caucho.vfs.ReadStream.read(ReadStream.java:306) [14:47:10.389] at com .caucho.server.cluster.ClusterStore.updateAccess(ClusterStore.java: 856) [14:47:10.389] at com .caucho.server.cluster.ClusterStore.accessServer(ClusterStore.java: 823) [14:47:10.389] at com.caucho.server.cluster.ClusterStore.accessImpl(ClusterStore.java: 804) [14:47:10.389] at com.caucho.server.cluster.ClusterObject.access(ClusterObject.java:337) [14:47:10.389] at com.caucho.server.session.SessionImpl.setAccess(SessionImpl.java:839) [14:47:10.389] at com.caucho.server.session.SessionManager.load(SessionManager.java: 1477) [14:47:10.389] at com .caucho.server.session.SessionManager.getSession(SessionManager.java: 1335) [14:47:10.389] at com .caucho .server .connection .AbstractHttpRequest.createSession(AbstractHttpRequest.java:1455) [14:47:10.389] at com .caucho .server .connection.AbstractHttpRequest.getSession(AbstractHttpRequest.java: 1270) [14:47:10.389] at net .sf .acegisecurity .context .HttpSessionContextIntegrationFilter .doFilter(HttpSessionContextIntegrationFilter.java:172) [14:47:10.389] at net.sf.acegisecurity.util.FilterChainProxy $VirtualFilterChain.doFilter(FilterChainProxy.java:303) [14:47:10.389] at net .sf .acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java: 173) [14:47:10.389] at net .sf .acegisecurity .util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:125) [14:47:10.389] at com .caucho .server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:73) --- Hessian failure stack trace --- [14:15:00.065] Caused by: org.springframework.web.util.NestedServletException : Hessian skeleton invocation failed; nested exception is java.io.IOException: expected 'c' in hessian input at -1 [14:15:00.065] at org .springframework .remoting .caucho .HessianServiceExporter.handleRequest(HessianServiceExporter.java:150) [14:15:00.065] at org.springframework.web.servlet.mvc.HttpRequestHandlerAdapter.handle (HttpRequestHandlerAdapter.java:49) [14:15:00.065] at org.springframework.web.servlet.DispatcherServlet.doDispatch (DispatcherServlet.java:857) [14:15:00.065] at org.springframework.web.servlet.DispatcherServlet.doService (DispatcherServlet.java:792) [14:15:00.065] at org.springframework.web.servlet.FrameworkServlet.processRequest (FrameworkServlet.java:475) [14:15:00.065] at org.springframework.web.servlet.FrameworkServlet.doPost (FrameworkServlet.java:440) [14:15:00.065] at ja
[Resin-interest] Resin cluster failure with a single node running out of heap space
Scott and others- My client has a five-node Resin Pro cluster, each running version 3.1.2. Today one of the nodes experienced an OutOfMemoryException which did not bring Resin down but seemed to have put it in a completely unresponsive state. With 10 minutes or so of that happening, the other four servers stop responding as well. Looking at their logs shows that they are continuously getting socket timeouts while trying to communicate with the first server for session clustering. (Stack trace below). To be fair, this is not the only exception being thrown. We also see our distributed EhCache system unsuccessfully trying to replicate itself. And we *also* see the occasional Hessian exception happening (also below). Ultimately the server just gets so bogged down, it seems, that it needs to be restarted. So my question is this: Assuming a Resin node runs out of memory, is there a way for other Resin nodes to detect that and take the same action as if the node was actually down? I'm not sure this is really a bug, but it is probably a good super-edge-case scenario worth thinking about. We are currently looking at our watchdog process config to see why it did not auto-restart Resin. I think we didn't give enough memory buffer for the watchdog to detect a needed restart, and our app lost responsiveness before the watchdog could restart it. But that's just a theory. I am interested in feedback from Scott and other Caucho developers about this issue, as well as other Resin users who may have experienced issues like this before and have any thoughts or suggestions on the matter. Thanks. ..mike.. --- Socket Timeout stack trace (partial) --- [14:47:10.389] java.net.SocketTimeoutException: Read timed out [14:47:10.389] at java.net.SocketInputStream.socketRead0(Native Method) [14:47:10.389] at java.net.SocketInputStream.read(SocketInputStream.java:129) [14:47:10.389] at com.caucho.vfs.TcpStream.read(TcpStream.java:163) [14:47:10.389] at com.caucho.vfs.ReadStream.readBuffer(ReadStream.java:1001) [14:47:10.389] at com.caucho.vfs.ReadStream.read(ReadStream.java:306) [14:47:10.389] at com.caucho.server.cluster.ClusterStore.updateAccess(ClusterStore.java:85 6) [14:47:10.389] at com.caucho.server.cluster.ClusterStore.accessServer(ClusterStore.java:82 3) [14:47:10.389] at com.caucho.server.cluster.ClusterStore.accessImpl(ClusterStore.java:804) [14:47:10.389] at com.caucho.server.cluster.ClusterObject.access(ClusterObject.java:337) [14:47:10.389] at com.caucho.server.session.SessionImpl.setAccess(SessionImpl.java:839) [14:47:10.389] at com.caucho.server.session.SessionManager.load(SessionManager.java:1477) [14:47:10.389] at com.caucho.server.session.SessionManager.getSession(SessionManager.java: 1335) [14:47:10.389] at com.caucho.server.connection.AbstractHttpRequest.createSession(AbstractH ttpRequest.java:1455) [14:47:10.389] at com.caucho.server.connection.AbstractHttpRequest.getSession(AbstractHttp Request.java:1270) [14:47:10.389] at net.sf.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilte r(HttpSessionContextIntegrationFilter.java:172) [14:47:10.389] at net.sf.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(F ilterChainProxy.java:303) [14:47:10.389] at net.sf.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.jav a:173) [14:47:10.389] at net.sf.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.j ava:125) [14:47:10.389] at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain. java:73) --- Hessian failure stack trace --- [14:15:00.065] Caused by: org.springframework.web.util.NestedServletException: Hessian skeleton invocation failed; nested exception is java.io.IOException: expected 'c' in hessian input at -1 [14:15:00.065] at org.springframework.remoting.caucho.HessianServiceExporter.handleRequest (HessianServiceExporter.java:150) [14:15:00.065] at org.springframework.web.servlet.mvc.HttpRequestHandlerAdapter.handle(Htt pRequestHandlerAdapter.java:49) [14:15:00.065] at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherS ervlet.java:857) [14:15:00.065] at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherSe rvlet.java:792) [14:15:00.065] at org.springframework.web.servlet.FrameworkServlet.processRequest(Framewor kServlet.java:475) [14:15:00.065] at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet .java:440) [14:15:00.065] at javax.servlet.http.HttpServlet.service(HttpServlet.java:153) [14:15:00.065] at javax.servlet.http.HttpServlet.service(HttpServlet.java:91) [14:15:00.065] at com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChai n.java:103) [14:15:00.065] at net.sf.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(F ilterChainProxy.java:292) [14:15:00.065] at taylor.tops.security.UserTrackerFilter.doFilter(UserTrackerFilter.java:2 7) [14:15
[Resin-interest] Managing separate watchdog processes in 3.1.5
Is there a way to specify what IP the watchdog-port will bind to? I want to be able to have a number of sites/instances of resin running on a machine I want all of them to run independent of each other so to keep them independent, I need to specify a watchdog-port... but if I do... it binds to the main ip of the machine... so in my scenario, I would need to assign each resin instance a unique port number. Is there a better way for me to handle this? Thanks Eric Kreiser ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] "java com.caucho.server.resin.Resin" and "java-jar resin.jar" behaves different
Hi Scott,
Did you prove that execution of resin.jar or httpd.exe would cause the
unexpected resource url?
Regards,
- Wesley
- Original Message -
From: "wesley" <[EMAIL PROTECTED]>
To: "General Discussion for the Resin application server"
Sent: Friday, March 07, 2008 12:28 PM
Subject: [Resin-interest] "java com.caucho.server.resin.Resin" and "java-jar
resin.jar" behaves different
Hi Scott,
> It seems the
> Thread.currentThread().getContextClassLoader().getResources("")
will produce the two urls,
one of which is
"/C:/JDK1.6.0/jre/lib/ext/meta-index/"
I've written a simple test and comfired it.
Should it be a bug of Resin.jar of httpd?
Regards,
- Wesley
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] java:comp/env/caucho/auth
Thanks champ, got it working again.
On Tue, Mar 11, 2008 at 4:26 AM, Scott Ferguson <[EMAIL PROTECTED]> wrote:
>
> On Mar 9, 2008, at 4:05 AM, Ron Pitts wrote:
>
> > Getting some werid problem using resin 3.1.5, I was using 3.1.4
> > without any problems but looks like my form login is now broken.
>
> Hmm. You need to add a jndi-name to the name="caucho/auth">, or even better, rewrite the FormLogin to look like:
>
> CFormLogin extends ... {
> @javax.webbeans.In
Re: [Resin-interest] java:comp/env/caucho/auth
On Mar 9, 2008, at 4:05 AM, Ron Pitts wrote:
> Getting some werid problem using resin 3.1.5, I was using 3.1.4
> without any problems but looks like my form login is now broken.
Hmm. You need to add a jndi-name to the , or even better, rewrite the FormLogin to look like:
CFormLogin extends ... {
@javax.webbeans.In ServletAuthenticator _auth;
...
}
When I updated the authenticator to use WebBeans, I'd thought the
"caucho/auth" name was only used internally to Resin, so removed the
default.
-- Scott
>
> Its returning an error javax.naming.NameNotFoundException: java:comp/
> env/caucho/auth
>
> Abtract of the class is as follows :
>
>
> public class CFormLogin extends com.caucho.server.security.FormLogin
>
> public ServletAuthenticator getAuthenticator()
> {
> log.debug("get servletauthenticator");
>
> if (_auth == null) {
> log.debug("auth = null");
> try {
> javax.naming.Context ic = new javax.naming.InitialContext();
> _auth = (ServletAuthenticator) ic.lookup("java:comp/env/
> caucho/auth");
> log.debug(_auth.toString());
> } catch (Exception e) {
> log.debug(e.toString());
> }
>
> Abtract of Web.xml
>
>
>
> jdbc/mysql
>
>
>
>
>
> formc
> Anonymous Form-Based Authentication Area name>
>
> /index.jsp
> /error.jsp
> /protected/menu.jsp
>
>
>
> /protected/login.jsp
> /error.jsp
> /protected/menu.jsp
>
>
>
>
> Any ideas
>
> thanks
>
> ___
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Quercus: Online docs incomplete in crucial area
On Mar 9, 2008, at 4:12 PM, Stargazer wrote: > Crucial for me right now anyway ;-) > http://quercus.caucho.com/quercus-3.1/doc/quercus.xtp#php.ini > The section under "JNDI DataSource ... WEB-INF/resin-web.xml" has > malformed xml for the tag. > Any chance of a fuller example please? I've just updated it. Basically, the underlying database support in Quercus is JDBC. So the only question is where the JDBC DataSource comes from. Setting the tag will force a specific, configured JDBC value to be used for all PHP calls, no matter what the parameters to the mysql_connect are. - Scott > > > The problem is I'm trying to associate a MySQL Pligg db on a different > server to the one resin 3.1.5 is running on. All my attempts to patch > things by updating the relevant *.php files stil result in > "localhost:3306" references in the error messages, when I really > want to > use (and see) "foo.com:3306" there. Nothing I am doing seems to > prevent > it from looking at localhost. > > The comment above the paragraph I mentioned seems strange too - it > suggests a db config there will override anything in the php scripts, > which is pretty much what I want. Does this really mean the params > defined in the php scripts are irrelevant? > > > > ___ > resin-interest mailing list > resin-interest@caucho.com > http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] small question about entity ejb
On Mar 10, 2008, at 1:29 AM, Riccardo Cohen wrote:
> Thanks a lot, I understand that I need a transaction now, while before
> it could work without this... I have no idea of how to do that.
>
> I noticed that in the doc of amber
> (http://caucho.com/resin/doc/amber.xtp) there was a
> @TransactionAnnotation but this makes a syntax error !
> Thanks to eclipse I found a @TransactionAnn, I added it at the
> beginning
> of my function definition, but this does not change (no update
> generated)
It should be @TransactionAttribute. I'm fixing the docs.
The @TransactionAttribute is the easiest method. You need to put it
on a Resin-IoC-aware object, e.g. a or an EJB stateless bean or
a servlet. If you put it on an arbitrary class, it won't do anything.
You can also use UserTransaction to do essentially the same thing:
class MyFoo {
@In UserTransaction _ut;
void myStuff()
{
_ut.begin();
try {
...
} finally {
ut.commit();
}
}
That's essentially identical to
@TransactionAttribute void myStuff()
{
...
}
If you turn logging level="fine", you'll see the transaction begin()/
commit(). So you can use the log to make sure the transactions are
working properly.
-- Scott
>
>
> Is there any doc about this ?
> Thanks
>
> Daniel López wrote:
>> Hi again,
>>
>> Some quick tests show that no persist() or merge() should be
>> necessary
>> to update an entity inside a persistent context. I tested with
>> Hibernate
>> and Amber as persistence providers and in both cases, nothing was
>> necessary. That was using Resin 3.1.5 and RESOURCE_LOCAL as
>> transaction
>> type, which means that the problem might be with the container
>> managed
>> transactions.
>>
>> S!
>> D.
>>
>> Daniel López escribió:
>>> AFAIK, using merge should not be necessary unless the entity has
>>> been
>>> updated outside a "persistent context" and then needs to be
>>> synchronised
>>> back with the DB contents. persist() is just for new entities so
>>> reading
>>> the docs, updating an entity inside a persistent context should
>>> require
>>> no action. Unless an exception is thrown, of course ;).
>>>
>>> I'm going to do some tests...
>>>
>>> S!
>>> D.
>>>
>>> Matt Johnston escribió:
I think you will need to use either the persist() or merge()
methods of
the EntityManager in order to save your data to the database. In
your
case since you are updating an existing record, you will need to
use:
m_manager.merge(homeobj)
Matt
Riccardo Cohen wrote:
> Hi
> I used to play with entity ejb with resin 3.0 with no problem.
> Now in
> 3.1.5 I have this code :
>
> @PersistenceContext(name="public") private EntityManager
> m_manager;
>
> public boolean set_homeinfo(int id_user,String title)
> {
> boolean success=false;
> Query hqr=m_manager.createQuery("select h from homeinfo h
> where
> h.id_user="+id_user);
> List hitems = (List)hqr.getResultList();
> if (hitems.size()==1)
> {
> homeinfo homeobj=hitems.get(0);
> System.out.println("title was "+homeobj.getTitle());
> homeobj.setTitle(title);
> success=true;
> }
> return(success);
> }
>
> The select works all right, but the "title" field is never
> modified. I
> added finer info on sql to see database requests in log, and
> there is no
> "update". Did I miss something ?
>
> I looked at the resin amber tutorials, but there are only "select"
> samples, I did not see "insert" and "update" samples... I remember
> problems like this with 3.0 when the entity bean was reused, it
> was not
> saved, but here it is not the case.
>
> Thanks for any help.
>>
>>
>>
>> ___
>> resin-interest mailing list
>> resin-interest@caucho.com
>> http://maillist.caucho.com/mailman/listinfo/resin-interest
>>
>
> --
> Très cordialement,
>
> Riccardo Cohen
> ---
> Articque
> http://www.articque.com
> 149 av Général de Gaulle
> 37230 Fondettes - France
> tel : 02-47-49-90-49
> fax : 02-47-49-91-49
>
>
> ___
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] small question about entity ejb
Thanks a lot, I understand that I need a transaction now, while before
it could work without this... I have no idea of how to do that.
I noticed that in the doc of amber
(http://caucho.com/resin/doc/amber.xtp) there was a
@TransactionAnnotation but this makes a syntax error !
Thanks to eclipse I found a @TransactionAnn, I added it at the beginning
of my function definition, but this does not change (no update generated)
Is there any doc about this ?
Thanks
Daniel López wrote:
> Hi again,
>
> Some quick tests show that no persist() or merge() should be necessary
> to update an entity inside a persistent context. I tested with Hibernate
> and Amber as persistence providers and in both cases, nothing was
> necessary. That was using Resin 3.1.5 and RESOURCE_LOCAL as transaction
> type, which means that the problem might be with the container managed
> transactions.
>
> S!
> D.
>
> Daniel López escribió:
>> AFAIK, using merge should not be necessary unless the entity has been
>> updated outside a "persistent context" and then needs to be synchronised
>> back with the DB contents. persist() is just for new entities so reading
>> the docs, updating an entity inside a persistent context should require
>> no action. Unless an exception is thrown, of course ;).
>>
>> I'm going to do some tests...
>>
>> S!
>> D.
>>
>> Matt Johnston escribió:
>>> I think you will need to use either the persist() or merge() methods of
>>> the EntityManager in order to save your data to the database. In your
>>> case since you are updating an existing record, you will need to use:
>>>
>>> m_manager.merge(homeobj)
>>>
>>>
>>> Matt
>>>
>>> Riccardo Cohen wrote:
Hi
I used to play with entity ejb with resin 3.0 with no problem. Now in
3.1.5 I have this code :
@PersistenceContext(name="public") private EntityManager m_manager;
public boolean set_homeinfo(int id_user,String title)
{
boolean success=false;
Query hqr=m_manager.createQuery("select h from homeinfo h where
h.id_user="+id_user);
List hitems = (List)hqr.getResultList();
if (hitems.size()==1)
{
homeinfo homeobj=hitems.get(0);
System.out.println("title was "+homeobj.getTitle());
homeobj.setTitle(title);
success=true;
}
return(success);
}
The select works all right, but the "title" field is never modified. I
added finer info on sql to see database requests in log, and there is no
"update". Did I miss something ?
I looked at the resin amber tutorials, but there are only "select"
samples, I did not see "insert" and "update" samples... I remember
problems like this with 3.0 when the entity bean was reused, it was not
saved, but here it is not the case.
Thanks for any help.
>
>
>
> ___
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest
>
--
Très cordialement,
Riccardo Cohen
---
Articque
http://www.articque.com
149 av Général de Gaulle
37230 Fondettes - France
tel : 02-47-49-90-49
fax : 02-47-49-91-49
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] small question about entity ejb
Hi again,
Some quick tests show that no persist() or merge() should be necessary
to update an entity inside a persistent context. I tested with Hibernate
and Amber as persistence providers and in both cases, nothing was
necessary. That was using Resin 3.1.5 and RESOURCE_LOCAL as transaction
type, which means that the problem might be with the container managed
transactions.
S!
D.
Daniel López escribió:
> AFAIK, using merge should not be necessary unless the entity has been
> updated outside a "persistent context" and then needs to be synchronised
> back with the DB contents. persist() is just for new entities so reading
> the docs, updating an entity inside a persistent context should require
> no action. Unless an exception is thrown, of course ;).
>
> I'm going to do some tests...
>
> S!
> D.
>
> Matt Johnston escribió:
>> I think you will need to use either the persist() or merge() methods of
>> the EntityManager in order to save your data to the database. In your
>> case since you are updating an existing record, you will need to use:
>>
>> m_manager.merge(homeobj)
>>
>>
>> Matt
>>
>> Riccardo Cohen wrote:
>>> Hi
>>> I used to play with entity ejb with resin 3.0 with no problem. Now in
>>> 3.1.5 I have this code :
>>>
>>>@PersistenceContext(name="public") private EntityManager m_manager;
>>>
>>>public boolean set_homeinfo(int id_user,String title)
>>>{
>>> boolean success=false;
>>> Query hqr=m_manager.createQuery("select h from homeinfo h where
>>> h.id_user="+id_user);
>>> List hitems = (List)hqr.getResultList();
>>> if (hitems.size()==1)
>>> {
>>>homeinfo homeobj=hitems.get(0);
>>>System.out.println("title was "+homeobj.getTitle());
>>>homeobj.setTitle(title);
>>>success=true;
>>> }
>>> return(success);
>>>}
>>>
>>> The select works all right, but the "title" field is never modified. I
>>> added finer info on sql to see database requests in log, and there is no
>>> "update". Did I miss something ?
>>>
>>> I looked at the resin amber tutorials, but there are only "select"
>>> samples, I did not see "insert" and "update" samples... I remember
>>> problems like this with 3.0 when the entity bean was reused, it was not
>>> saved, but here it is not the case.
>>>
>>> Thanks for any help.
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] small question about entity ejb
AFAIK, using merge should not be necessary unless the entity has been
updated outside a "persistent context" and then needs to be synchronised
back with the DB contents. persist() is just for new entities so reading
the docs, updating an entity inside a persistent context should require
no action. Unless an exception is thrown, of course ;).
I'm going to do some tests...
S!
D.
Matt Johnston escribió:
> I think you will need to use either the persist() or merge() methods of
> the EntityManager in order to save your data to the database. In your
> case since you are updating an existing record, you will need to use:
>
> m_manager.merge(homeobj)
>
>
> Matt
>
> Riccardo Cohen wrote:
>> Hi
>> I used to play with entity ejb with resin 3.0 with no problem. Now in
>> 3.1.5 I have this code :
>>
>>@PersistenceContext(name="public") private EntityManager m_manager;
>>
>>public boolean set_homeinfo(int id_user,String title)
>>{
>> boolean success=false;
>> Query hqr=m_manager.createQuery("select h from homeinfo h where
>> h.id_user="+id_user);
>> List hitems = (List)hqr.getResultList();
>> if (hitems.size()==1)
>> {
>>homeinfo homeobj=hitems.get(0);
>>System.out.println("title was "+homeobj.getTitle());
>>homeobj.setTitle(title);
>>success=true;
>> }
>> return(success);
>>}
>>
>> The select works all right, but the "title" field is never modified. I
>> added finer info on sql to see database requests in log, and there is no
>> "update". Did I miss something ?
>>
>> I looked at the resin amber tutorials, but there are only "select"
>> samples, I did not see "insert" and "update" samples... I remember
>> problems like this with 3.0 when the entity bean was reused, it was not
>> saved, but here it is not the case.
>>
>> Thanks for any help.
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
