[Resin-interest] Replication of Principals

2009-06-24 Thread Daniel D'Alessandro
Hi I'm using resin 3.1.6 and I've run into an issue in our clustered 
environment. When a client hits our application for the first time we 
authenticate them as a guest and then the user may re-authenticate using 
their client credentials.

What seems to be happening is a client hits server 1 and get 
authenticated as a guest, they then login on server 2 and get a new 
principal associated with their session. Later on they get directed back 
to server 1 and while the session detail is replicated it is once again 
associated with the guest principal from when they first visited.

If the two principals are created on the one machine and then the user 
is directed to the second server everything is fine.

I'm in the early stages of fully diagnosing this but can anyone confirm 
this is the case and if its fixed in a later version?

Thanks,
Dan


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest


[Resin-interest] Ear deployment and virtualhosts

2008-07-08 Thread Daniel D'Alessandro
I have an ear file with say 2 wars underneath it. These 2 wars share the 
same middle layer (EJB3 + hibernate)
and I want to map the 2 webapps to different hosts and only those hosts.

at the moment with an ear deployment I'm allowed

webapp1 -> somedomain.com
webapp2 -> somedomain.com/admin

I want to be able to do

webapp1  -> somedomain.com
webapp2  -> admin.somedomain.com

without having to redeploy my middle tier twice which would result in 2 
copies of all my session beans and hibernate etc.

I did find this thread 
http://maillist.caucho.com/pipermail/resin-interest/2008-March/002174.html 
but the resulting bug
at the end of the thread has been closed with no resolution needed. Does 
this mean the functionality will be present in
3.2 or not at all? I suppose taking the war's out of the ear and 
deploying them independently is possible but far from ideal,
as it raises issues of local vs remote interfaces and other deployment 
problems. 

Regards,
Dan


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest


[Resin-interest] major change in transactional behaviour in snapshot from 2008-03-04

2008-03-13 Thread Daniel D'Alessandro
Hi all,

I've noticed a fairly major change in the transactional behaviour in the 
snapshot from 2008-03-04

basically if I have a session bean set up in the following manner

public interface IFoo
{
   public method1();

   public method2();
}

@Stateless
@Local ({IFoo.class})
@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
public class FooImpl implements IFoo
{
   public method1()
   {
//do stuff
   }

   public method2()
   {
  method1()
  //do stuff
   }
}

now under the older resin (and other appservers I've used) the call from 
method2 to method1 would not result in a new transaction, instead method1 
would participate in the transaction started by method2. To get the 
requires new you would have to call another instance of Foo.
In the snapshot method1 called in this manner will start a new transaction if 
it is on 
the local interface.

Was this the desired result?

Dan






___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest